home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-187 < prev    next >
Encoding:
Text File  |  1988-12-01  |  124.0 KB  |  4,197 lines

  1.  
  2.                                                           IEN 187
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.                      ISSUES IN INTERNETTING
  22.  
  23.                  PART 2:  ACCESSING THE INTERNET
  24.  
  25.  
  26.                           Eric C. Rosen
  27.  
  28.  
  29.                   Bolt Beranek and Newman Inc.
  30.  
  31.  
  32.                             June 1981
  33.  
  34.  
  35. IEN 187                              Bolt Beranek and Newman Inc.
  36.                                                     Eric C. Rosen
  37.  
  38.  
  39.                      ISSUES IN INTERNETTING
  40.  
  41.                  PART 2:  ACCESSING THE INTERNET
  42.  
  43.  
  44. 2.  Accessing the Internet
  45.  
  46.  
  47.  
  48.      This is the second in a series of papers, the first of which
  49.  
  50. was IEN 184, that examine some of  the  issues  in  designing  an
  51.  
  52. internet.    Familiarity  with  IEN  184  is  presupposed.   This
  53.  
  54. particular paper will deal with the issues involved in the design
  55.  
  56. of  internet  access  protocols  and  software.   The  issue   of
  57.  
  58. addressing, however, is left until the next paper in this series.
  59.  
  60. Part of our technique for exposing and organizing the issues will
  61.  
  62. be to criticize (sometimes rather severely) the current protocols
  63.  
  64. and  procedures  of  the  Catenet,  even though we do not, at the
  65.  
  66. present time, offer specific alternatives in all cases.
  67.  
  68.  
  69.      In IEN 184, section 1.4,  we  outlined  four  steps  in  the
  70.  
  71. operation  of a Network Structure.  Let's now look closely at the
  72.  
  73. first step, viz., how the source Host actually submits a  message
  74.  
  75. to  the source Switch.  In general, a Host will need to run three
  76.  
  77. separate protocols to do this:
  78.  
  79.  
  80.     -a protocol to utilize the electrical interface  between  the
  81.  
  82.      Host  and  the  initial  component of the Pathway it uses to
  83.  
  84.      access the source Switch.
  85.  
  86.  
  87.  
  88.  
  89.  
  90.                               - 1 -
  91.  
  92.  
  93. IEN 187                              Bolt Beranek and Newman Inc.
  94.                                                     Eric C. Rosen
  95.  
  96.  
  97.     -a protocol to govern communication between the Host and  the
  98.  
  99.      Pathway (PATHWAY ACCESS PROTOCOL).
  100.  
  101.  
  102.     -a protocol to govern communication between the Host and  the
  103.  
  104.      source Switch (NETWORK ACCESS PROTOCOL).
  105.  
  106.  
  107.      We  can  make  this  point  more  concrete  by  giving  some
  108.  
  109. examples.  Consider the case of an ARPANET host  which  wants  to
  110.  
  111. access  the  Catenet via the BBN gateway (which is also a Host on
  112.  
  113. the ARPANET).  Then the ARPANET is the Pathway the host  uses  to
  114.  
  115. access  the  source Switch (the gateway).  If the host is a local
  116.  
  117. or distant host, the electrical interface to the Pathway  is  the
  118.  
  119. 1822  hardware  interface.   If  it is a VDH host, the electrical
  120.  
  121. interface is whatever protocol governs the use of the pins on the
  122.  
  123. modem connectors.  If it were an X.25 host, the  interface  might
  124.  
  125. be X.21.  The PATHWAY ACCESS PROTOCOL is the 1822 protocol, which
  126.  
  127. governs  communication  between the host and the first IMP on the
  128.  
  129. Pathway.  The NETWORK ACCESS PROTOCOL in this case would  be  the
  130.  
  131. DoD  standard Internet Protocol (IP), which governs communication
  132.  
  133. between the host and the source Switch (gateway).
  134.  
  135.  
  136.      If, on the other hand, we consider the case  of  an  ARPANET
  137.  
  138. host which is communicating with another host on the ARPANET, and
  139.  
  140. whose data stays purely within the ARPANET, 1822 becomes both the
  141.  
  142. NETWORK ACCESS PROTOCOL (since the source Switch is now identical
  143.  
  144. to  the  source  IMP), and the PATHWAY ACCESS PROTOCOL, since the
  145.  
  146. Pathway is now the 1822 hardware connection.
  147.  
  148.                               - 2 -
  149.  
  150.  
  151. IEN 187                              Bolt Beranek and Newman Inc.
  152.                                                     Eric C. Rosen
  153.  
  154.  
  155.      We will have nothing further to  say  about  the  electrical
  156.  
  157. interface,  since  that is really just a straightforward hardware
  158.  
  159. matter.   (However,  such  characteristics  of   the   electrical
  160.  
  161. interface  as error rate, for example, might have to be reflected
  162.  
  163. in the design of the Pathway Access  Protocol.)   The  design  of
  164.  
  165. both  the Pathway Access Protocol and the Network Access Protocol
  166.  
  167. do raise a large number of interesting issues, and that shall  be
  168.  
  169. the focus of this paper.
  170.  
  171.  
  172.      We  believe  it  to  be very unlikely that Host software (or
  173.  
  174. gateway software) can utilize the internet efficiently unless  it
  175.  
  176. takes  the idiosyncrasies of BOTH the Pathway Access Protocol and
  177.  
  178. the Network Access Protocol into  account.   A  gateway  or  host
  179.  
  180. software  implementer  who  spends a great deal of time carefully
  181.  
  182. building his IP module, but who then writes a "quick  and  dirty"
  183.  
  184. 1822  module,  is likely to find that his inefficient use of 1822
  185.  
  186. completely sabotages the advantages which his carefully  designed
  187.  
  188. IP  is  supposed  to have.  Experience with the ARPANET has shown
  189.  
  190. many times that  poorly  constructed  host  software  can  create
  191.  
  192. unnecessary  performance  problems.   It seems, for example, that
  193.  
  194. many 1822 modules completely ignore the flow control restrictions
  195.  
  196. of the ARPANET, thereby  significantly  reducing  the  throughput
  197.  
  198. that  they can obtain over the ARPANET.  We have even encountered
  199.  
  200. many hosts which cannot  properly  handle  some  of  the  control
  201.  
  202. messages  of  the  1822  protocol,  which  also  leads  to a very
  203.  
  204. inefficient use of the ARPANET.
  205.  
  206.                               - 3 -
  207.  
  208.  
  209. IEN 187                              Bolt Beranek and Newman Inc.
  210.                                                     Eric C. Rosen
  211.  
  212.  
  213.      It is not difficult to understand why a  host  (or  gateway)
  214.  
  215. software  implementer might overlook the issues having to do with
  216.  
  217. the proper use of the  Pathway  Access  Protocol.   There  are  a
  218.  
  219. number  of  pressures  that,  if  not  dealt  with  properly at a
  220.  
  221. management level, lead naturally to the neglect of Pathway Access
  222.  
  223. Protocol  issues.   An  internet  implementer   might   want   to
  224.  
  225. concentrate   on  the  "new  stuff",  viz.,  the  Network  Access
  226.  
  227. Protocol,  IP,  and  may  not  be  at  all  interested   in   the
  228.  
  229. idiosyncrasies  of  the older Pathway Access Protocol (1822).  He
  230.  
  231. might be misled, by the belief that the packet-switching networks
  232.  
  233. underlying  the  internet  should  be  transparent  to  it,  into
  234.  
  235. believing  that those packet-switching networks can be treated as
  236.  
  237. simply as if they were circuits.  He might also be under pressure
  238.  
  239. to implement as quickly as possible the  necessary  functionality
  240.  
  241. to  allow  internet  access.  While this sort of pressure is very
  242.  
  243. common, the pressure  to  make  the  internet  PERFORM  well  (as
  244.  
  245. opposed  to  the  pressure  simply  to  make  it  work at all) is
  246.  
  247. generally not felt  until  much  (sometimes  years)  later.   The
  248.  
  249. tendency  to  neglect performance considerations while giving too
  250.  
  251. much attention to simply obtaining the  needed  functionality  in
  252.  
  253. the  quickest  way  is  also  reinforced  by such "modern" design
  254.  
  255. procedures as top-down design, and specification of protocols  in
  256.  
  257. formal  languages.  While these procedures do have a large number
  258.  
  259. of advantages, they also serve to obscure performance issues.  If
  260.  
  261. the researchers and  designers  of  protocols,  following  modern
  262.  
  263.  
  264.                               - 4 -
  265.  
  266.  
  267. IEN 187                              Bolt Beranek and Newman Inc.
  268.                                                     Eric C. Rosen
  269.  
  270.  
  271. design  methodologies,  do  not  give  adequate  consideration to
  272.  
  273. performance at the time of protocol design, one can hardly expect
  274.  
  275. the implementers to do so.   Yet  ARPANET  experience  has  shown
  276.  
  277. again   and   again   that   decisions   made  at  the  level  of
  278.  
  279. implementation, apparently too picayune to catch the attention of
  280.  
  281. the designers, can  be  important  determinants  of  performance.
  282.  
  283. Still  another  reason  why  protocol software implementers might
  284.  
  285. tend to disregard the niceties of the Pathway Access Protocol  is
  286.  
  287. the   lack   of  any  adequate  protocol  software  certification
  288.  
  289. procedure.  An ARPANET host could be  connected  to  an  IMP  for
  290.  
  291. months,  transferring  large  amounts  of  traffic,  without ever
  292.  
  293. receiving certain 1822  control  messages.   Then  some  sort  of
  294.  
  295. change  in  network conditions could suddenly cause it to receive
  296.  
  297. that control message once per hour.  There really is  no  way  at
  298.  
  299. present  that  the  implementer  could have possibly run tests to
  300.  
  301. ensure that his software would continue to perform well under the
  302.  
  303. new circumstances.  This problem is somewhat  orthogonal  to  our
  304.  
  305. main interests, but deserves notice.
  306.  
  307.  
  308.      One  of  the  most  important  reasons why protocol software
  309.  
  310. implementers tend to ignore the details  of  the  Pathway  Access
  311.  
  312. Protocols  is  the  "philosophical" belief that anyone working on
  313.  
  314. internet software really "ought not" to have to worry  about  the
  315.  
  316. details  of  the  underlying  networks.   We  will not attempt to
  317.  
  318. refute this view, any more than we would attempt  to  refute  the
  319.  
  320. view  of  a person who claimed that it "ought not" to rain on his
  321.  
  322.                               - 5 -
  323.  
  324.  
  325. IEN 187                              Bolt Beranek and Newman Inc.
  326.                                                     Eric C. Rosen
  327.  
  328.  
  329. day off.  We emphasized in IEN 184 that the characteristics of  a
  330.  
  331. Network  Structure's Pathways are the main thing that distinguish
  332.  
  333. one Network Structure from another,  and  that  the  problems  of
  334.  
  335. internetting  really  are  just  the  problems  of how to build a
  336.  
  337. Network   Structure   with    Pathways    as    ill-behaved    as
  338.  
  339. packet-switching  networks.   Thus building a successful internet
  340.  
  341. would seem to be  a  matter  of  dealing  specifically  with  the
  342.  
  343. behavior  of  the  various  Pathways,  rather  than ignoring that
  344.  
  345. behavior.  We assume that that our task is to create an  internet
  346.  
  347. which  is robust and which performs well, as opposed to one which
  348.  
  349. "ought to" perform well but does not.  It is  true,  as  we  have
  350.  
  351. said,  that  within the Network Structure of the Catenet, we want
  352.  
  353. to regard the ARPANET as a Pathway whose internal structure we do
  354.  
  355. not have to deal with, but that does  NOT  mean  that  we  should
  356.  
  357. regard  it  as a circuit.  Any internet Host or Switch (gateway),
  358.  
  359. TO PERFORM WELL, will have to have a carefully designed and tuned
  360.  
  361. Pathway Access Protocol module geared to the  characteristics  of
  362.  
  363. the Pathway that it accesses.
  364.  
  365.  
  366.      The relationship between the Pathway Access Protocol and the
  367.  
  368. Network  Access  Protocol  does  offer  a  number  of interesting
  369.  
  370. problems.  For one thing, it appears that these protocols do  not
  371.  
  372. fit  easily into the OSI Open Systems model.  If we are accessing
  373.  
  374. a single packet-switching network, the  Network  Access  Protocol
  375.  
  376. appears  to  be  a  level  3  protocol  in the OSI model, and the
  377.  
  378. Pathway Access  Protocol  appears  to  be  a  level  2  protocol.
  379.  
  380.                               - 6 -
  381.  
  382.  
  383. IEN 187                              Bolt Beranek and Newman Inc.
  384.                                                     Eric C. Rosen
  385.  
  386.  
  387. However, if we are accessing an internet, we still need the level
  388.  
  389. 3  Network  Access  Protocol, but now the Pathway Access Protocol
  390.  
  391. also has a  level  3  component,  in  addition  to  its  level  2
  392.  
  393. component.   So  the  Host  is  now running two different level 3
  394.  
  395. protocols,  although  the   Network   Access   Protocol   appears
  396.  
  397. functionally  to  be  in  a layer "above" the level 3 part of the
  398.  
  399. Pathway Access Protocol.  Perhaps the main problem here  is  that
  400.  
  401. the   OSI  model  has  insufficient  generality  to  capture  the
  402.  
  403. structure of the protocols needed to access an internet like  the
  404.  
  405. Catenet.
  406.  
  407.  
  408.      It  is  interesting  to see how some of these considerations
  409.  
  410. generalize to the case  of  a  Host  which  needs  to  access  an
  411.  
  412. internet  (call  it  "B")  through  a  Pathway which is itself an
  413.  
  414. internet (call it "A").  Then the Host  needs  a  Network  Access
  415.  
  416. Protocol  for  the  internet B, a Network Access Protocol for the
  417.  
  418. internet A  (which  is  also  its  Pathway  Access  Protocol  for
  419.  
  420. internet B), and a Network Access Protocol for the actual network
  421.  
  422. to  which  it  is  directly  connected, which is also its Pathway
  423.  
  424. Access Protocol for internet A.   As  we  create  more  and  more
  425.  
  426. complicated  Network  Structures,  with internets piled on top of
  427.  
  428. internets, the Hosts will have a  greater  and  greater  protocol
  429.  
  430. burden  placed  upon  them.  Ultimately, we might want to finesse
  431.  
  432. this problem by removing most of this burden from the  Hosts  and
  433.  
  434. putting  it in the Switches, and giving the Switches knowledge of
  435.  
  436. the hierarchical nature of the (internet) Network Structure.  For
  437.  
  438.                               - 7 -
  439.  
  440.  
  441. IEN 187                              Bolt Beranek and Newman Inc.
  442.                                                     Eric C. Rosen
  443.  
  444.  
  445. example, a Host on the ARPANET might just want to give  its  data
  446.  
  447. to  some  IMP to which it is directly connected, without worrying
  448.  
  449. at all about whether that data will need to leave the ARPANET and
  450.  
  451. travel via an internet.  The IMP could  decide  whether  that  is
  452.  
  453. necessary, and if so, execute the appropriate protocol to get the
  454.  
  455. data  to  some  internet  Switch  at  the  next  highest level of
  456.  
  457. hierarchy.  If the data cannot reach its destination  within  the
  458.  
  459. internet  at  that  level, but rather has to go up further in the
  460.  
  461. hierarchy to another internet, the  Switch  at  the  lower  level
  462.  
  463. could  make  that  decision and execute the appropriate protocol.
  464.  
  465. With a protocol structure like this, we could have an arbitrarily
  466.  
  467. nested internet, and the Switches at a particular level, as  well
  468.  
  469. as  the Hosts (which are at the lowest level), would only have to
  470.  
  471. know how to access the levels of hierarchy which are  immediately
  472.  
  473. above and/or below them.  This procedure would also make the host
  474.  
  475. software  conform  more  to the OSI model, since only one Network
  476.  
  477. Access  Protocol  would  be  required.   However,  this  sort  of
  478.  
  479. protocol structure, convenient as it might be for the Hosts, does
  480.  
  481. not eliminate any of the issues about how to most efficiently use
  482.  
  483. the  Pathways  of  a  Network  Structure.  Rather, it just pushes
  484.  
  485. those issues up one level, and makes the Switches correspondingly
  486.  
  487. more  complicated.   A  proper  understanding  of   the   issues,
  488.  
  489. therefore, is independent of what sort of protocol structuring we
  490.  
  491. design.
  492.  
  493.  
  494.  
  495.  
  496.                               - 8 -
  497.  
  498.  
  499. IEN 187                              Bolt Beranek and Newman Inc.
  500.                                                     Eric C. Rosen
  501.  
  502.  
  503.      Having  emphasized  the  need for hosts and gateways to take
  504.  
  505. account of the details of particular Pathway Access Protocols, we
  506.  
  507. must point out that this is not always a simple thing to do.   If
  508.  
  509. the  Network  Structure  underlying  a  Pathway  is just a single
  510.  
  511. network, like the  ARPANET,  this  problem  is  not  so  terribly
  512.  
  513. difficult,  since  one  can expect that there will be available a
  514.  
  515. lot of experience and information about what a host should do  to
  516.  
  517. access  that  network  efficiently.   If,  on the other hand, the
  518.  
  519. Pathway is  really  an  internet  itself,  the  problem  is  more
  520.  
  521. difficult,  since  it  is  much  more  difficult  to say anything
  522.  
  523. substantive about its characteristics.  This is a point  we  must
  524.  
  525. keep  in  mind  as  we discuss specific issues in access protocol
  526.  
  527. design.
  528.  
  529.  
  530.      In the remainder of this paper, we will attempt to deal with
  531.  
  532. a  number  of  issues  involved  in   the   design   of   robust,
  533.  
  534. high-performance  Network  and Pathway Access Protocols.  We will
  535.  
  536. not attempt to cover every possible issue here.   In  particular,
  537.  
  538. the  issue of how to do addressing is important enough to warrant
  539.  
  540. a paper of its own, and shall be put off until the next paper  in
  541.  
  542. this series.  We will attempt throughout to focus on issues which
  543.  
  544. particularly affect the reliability of the internet configuration
  545.  
  546. (as  perceived  by  the  users),  and  on issues which affect the
  547.  
  548. performance  of  the  internet  (as  perceived  by  the   users).
  549.  
  550. Wherever  possible,  we  will try to exhibit the way in which the
  551.  
  552. reliability and performance of a protocol trade off  against  its
  553.  
  554.                               - 9 -
  555.  
  556.  
  557. IEN 187                              Bolt Beranek and Newman Inc.
  558.                                                     Eric C. Rosen
  559.  
  560.  
  561. functionality.   If protocol designers concentrate too heavily on
  562.  
  563. questions of what functionality is desired, as  opposed  to  what
  564.  
  565. functionality   can   be   provided  at  a  reasonable  level  of
  566.  
  567. performance and reliability, they are likely to find out too late
  568.  
  569. that  the  protocol  gives  neither  reasonable  performance  nor
  570.  
  571. reliability.
  572.  
  573.  
  574. 2.1  Pathway Up/Down Considerations
  575.  
  576.  
  577.      In  general,  a  Host  will be multi-homed to some number of
  578.  
  579. Switches.  In fact, it is easy to imagine a Host  which  is  both
  580.  
  581. (a) multi-homed to a number of IMPs, within the Network Structure
  582.  
  583. of  the  ARPANET  (this cannot be done at present, but is planned
  584.  
  585. for the future), and also (b) multi-homed to a number of gateways
  586.  
  587. (namely, all the gateways on  the  ARPANET)  within  the  Network
  588.  
  589. Structure  of  the  Catenet.  Whenever a Host is multi-homed to a
  590.  
  591. number of Switches in some Network Structure, it has  a  decision
  592.  
  593. to  make,  namely,  which  of those Switches to use as the source
  594.  
  595. Switch for some particular data traffic.  In order to  make  this
  596.  
  597. choice,  the  very  first  step  a  Host  will have to take is to
  598.  
  599. determine  which  Switches  it  can  reach  through   operational
  600.  
  601. Pathways.  One thing we can say for sure is that if a Host cannot
  602.  
  603. reach  a  particular Switch through any of its possible Pathways,
  604.  
  605. then it ought not to pick that Switch as  the  source  Switch  to
  606.  
  607. which  to  send  its  data.   In  a  case, for example, where the
  608.  
  609. ARPANET is partitioned, a Host on the ARPANET which needs to send
  610.  
  611.  
  612.                              - 10 -
  613.  
  614.  
  615. IEN 187                              Bolt Beranek and Newman Inc.
  616.                                                     Eric C. Rosen
  617.  
  618.  
  619. internet traffic will want to know which gateways  it  can  reach
  620.  
  621. through   which   of   its  ARPANET  interfaces.   To  make  this
  622.  
  623. determination possible, there  must  be  some  sort  of  "Pathway
  624.  
  625. Up/Down  Protocol",  by  which  the  Host determines which of its
  626.  
  627. potential Pathways to gateways are up and which are  down.   This
  628.  
  629. is  not  to  say,  of  course,  that the Hosts have to know which
  630.  
  631. gateways are up and which are down, but rather,  they  must  know
  632.  
  633. which  gateways  they  can  and  cannot  reach.   Of course, this
  634.  
  635. situation  is  quite  symmetric.   The  Switches  of  a   Network
  636.  
  637. Structure  (and  in particular, the gateways of an internet) must
  638.  
  639. be  able  to  determine  whether  or  not  they  can  reach  some
  640.  
  641. particular  host at some particular time.  Otherwise, the gateway
  642.  
  643. might send traffic for a certain Host over a network access  line
  644.  
  645. through  which  there  is  no  path to that Host, thereby causing
  646.  
  647. unnecessary data loss.  Apparently,  this  problem  has  occurred
  648.  
  649. with  some  frequency in the Catenet; it seems worthwhile to give
  650.  
  651. it some systematic consideration.
  652.  
  653.  
  654.      The design of reliable Pathway Up/down protocols seems  like
  655.  
  656. something  that  "ought  to be" trivial, but in fact can be quite
  657.  
  658. difficult.  Let's begin by considering the  case  of  an  ARPANET
  659.  
  660. host  which  simply  wants to determine whether it can reach some
  661.  
  662. IMP to which it is directly connected.  The first  step  for  the
  663.  
  664. host to take (if it is a local or distant host) is to look at the
  665.  
  666. status  of  its Ready Line.  If the Ready Line to some IMP is not
  667.  
  668. up, then it is certain that communication with that  IMP  is  not
  669.  
  670.                              - 11 -
  671.  
  672.  
  673. IEN 187                              Bolt Beranek and Newman Inc.
  674.                                                     Eric C. Rosen
  675.  
  676.  
  677. possible.   If  the  host  is a VDH host, then there is a special
  678.  
  679. up/down protocol that the host must participate in with the  IMP,
  680.  
  681. and if that fails, the host knows that it cannot communicate with
  682.  
  683. the  IMP.  Of course, these situations are symmetric, in that the
  684.  
  685. IMP has the same need to know whether it can communicate  with  a
  686.  
  687. host,  and  must  follow the same procedures to determine whether
  688.  
  689. this is the case.  However, even  in  these  very  simple  cases,
  690.  
  691. problems  are  possible.   For  example,  someone  may  decide to
  692.  
  693. interface a host to an IMP via a "clever" front-end  which  hides
  694.  
  695. the  status  of the Ready Line from the host software.  If a host
  696.  
  697. is multi-homed, and has to choose one from among several possible
  698.  
  699. source IMPs, but cannot "see" the Ready Lines, what would stop it
  700.  
  701. from sending messages to a dead IMP?  Eventually,  of  course,  a
  702.  
  703. user would notice that his data is not getting through, and would
  704.  
  705. probably  call  up the ARPANET Network Control Center to complain
  706.  
  707. about  the  unreliability  of  the  network,  which,   from   his
  708.  
  709. perspective, is mysteriously dropping packets.  From the opposite
  710.  
  711. perspective,  one  must  realize that such a front-end might also
  712.  
  713. hide the status of the host from the IMP, so that the network has
  714.  
  715. no way of knowing whether a particular host is currently  capable
  716.  
  717. of  communicating with the network.  This is especially likely to
  718.  
  719. happen if the "clever" front-end takes packets from  the  network
  720.  
  721. which  are  destined  for  a particular host, and then just drops
  722.  
  723. them if the host is down, with no feedback to either IMP or host.
  724.  
  725. If a host is multi-homed, but one of its access  lines  is  down,
  726.  
  727.  
  728.                              - 12 -
  729.  
  730.  
  731. IEN 187                              Bolt Beranek and Newman Inc.
  732.                                                     Eric C. Rosen
  733.  
  734.  
  735. this  sort of configuration might make it quite difficult for the
  736.  
  737. network to reach a reasonable decision as to which access line to
  738.  
  739. use when sending data to that host.  The lesson,  of  course,  is
  740.  
  741. that the status of the Ready Line should never be hidden from the
  742.  
  743. host  software,  but it is hard to communicate this lesson to the
  744.  
  745. designers  of  host  software.   Again,  the  issue  is  one   of
  746.  
  747. performance  vs.  functionality.  A scheme which hides the status
  748.  
  749. of the Ready Line from IMP or host may still  have  the  required
  750.  
  751. (minimum)  functionality,  but  it will just perform poorly under
  752.  
  753. certain conditions.
  754.  
  755.  
  756.      This may seem like a made-up problem  which  probably  would
  757.  
  758. never  occur,  but in fact it has occurred.  We once had a series
  759.  
  760. of complaints from a user who claimed that at  certain  times  of
  761.  
  762. certain  days  he  had  been unable to transmit data successfully
  763.  
  764. over the ARPANET.  Upon investigation, we found that during those
  765.  
  766. times, the user's local IMP had been powered down, due apparently
  767.  
  768. to a series of local power  failures  at  the  user's  site.   Of
  769.  
  770. course,  the  IMP will not transmit data when it is powered down.
  771.  
  772. But it was somewhat mysterious why we had to inform someone of  a
  773.  
  774. power  failure  at  his  own site; surely the host software could
  775.  
  776. have detected that the IMP was down simply by checking the  Ready
  777.  
  778. Line, and so informed the users.  When this user investigated his
  779.  
  780. own host software (a very old NCP), he found that it would inform
  781.  
  782. the  users  that the IMP was down ONLY if the IMP sent the host a
  783.  
  784. message saying that it was going down.  Since the  IMP  does  not
  785.  
  786.                              - 13 -
  787.  
  788.  
  789. IEN 187                              Bolt Beranek and Newman Inc.
  790.                                                     Eric C. Rosen
  791.  
  792.  
  793. send  a  message  saying that it is about to lose power, the host
  794.  
  795. software, which apparently did not check  the  Ready  Line  as  a
  796.  
  797. matter  of  course,  did not detect the outage.  It looked to the
  798.  
  799. user, therefore, as though the network had  some  mysterious  and
  800.  
  801. unreliable  way  of dropping packets on the floor.  It seems that
  802.  
  803. many hosts presently exist whose networking software is based  on
  804.  
  805. the  assumption  that  the  IMPs  never  go down without warning.
  806.  
  807. Hosts do sometimes  have  difficulty  determining  whether  their
  808.  
  809. Pathway  to  an  IMP  is up or down, even when it seems like this
  810.  
  811. should be totally trivial to determine.  Reliable network service
  812.  
  813. requires, however, that host software and hardware  designers  do
  814.  
  815. not  hide  the  status of the IMP from the host, or the status of
  816.  
  817. the host from the IMP.  This will become  increasingly  important
  818.  
  819. as more and more hosts become multi-homed.
  820.  
  821.  
  822.      Of  course,  this  is  only a first step in a proper up/down
  823.  
  824. determination.  It is not impossible for a Ready Line  to  be  up
  825.  
  826. but   for   some  problem  either  in  IMP  or  host  to  prevent
  827.  
  828. communications from taking place.  So some higher  level  up/down
  829.  
  830. protocol  is  also necessary.  Some protocol should be defined by
  831.  
  832. which Host and Switch can send traffic to each other, and require
  833.  
  834. the other to respond within a certain time period.  A  series  of
  835.  
  836. failures  to respond would indicate that proper communications is
  837.  
  838. not possible, at least for the time being.  It  is  important  to
  839.  
  840. note,  though,  that the need for a higher level up/down protocol
  841.  
  842. does not obviate the  need  for  the  lower  level  procedure  of
  843.  
  844.                              - 14 -
  845.  
  846.  
  847. IEN 187                              Bolt Beranek and Newman Inc.
  848.                                                     Eric C. Rosen
  849.  
  850.  
  851. monitoring  the Ready Line.  If the higher level procedure fails,
  852.  
  853. but the Ready Line appears to be up, knowledge of both  facts  is
  854.  
  855. needed   for   proper  fault  isolation  and  maintenance.   Also
  856.  
  857. important  to  notice  is  that  if  the  lower  level  procedure
  858.  
  859. indicates  that  the  Pathway is down, the higher level procedure
  860.  
  861. should not be run.   This  might  not  seem  important  at  first
  862.  
  863. glance,  but  in  practice, it often turns out that attempting to
  864.  
  865. send traffic to a non-responsive machine results  in  significant
  866.  
  867. waste  of resources that could be used for something more useful.
  868.  
  869.  
  870.      In the more general case, where a Host's Pathway to a source
  871.  
  872. Switch may include one or more packet-switching networks,  it  is
  873.  
  874. far  from  trivial to determine whether the Switch can be reached
  875.  
  876. from the Host via the Pathway.   Consider,  for  example,  how  a
  877.  
  878. given  ARPANET  host  could  determine  whether  a  given Catenet
  879.  
  880. gateway on the ARPANET can be accessed  via  some  given  ARPANET
  881.  
  882. source  IMP.   Of  course, the first step is to determine whether
  883.  
  884. communication with that source IMP is possible.  Even if  it  is,
  885.  
  886. however,  the gateway might still be unreachable, since it may be
  887.  
  888. down, or the network may be  partitioned.   ("Officially",  every
  889.  
  890. ARPANET  Host  is supposed to be reachable from any other ARPANET
  891.  
  892. Host.  However, the average connectivity of the ARPANET  is  only
  893.  
  894. 2.5,  which  means  that  only  a  small  number  of line or node
  895.  
  896. failures are needed to induce  partitions.   Furthermore,  a  few
  897.  
  898. ARPANET  sites  are  actually  stubs,  which  means that a single
  899.  
  900. failure can isolate them from the rest of the ARPANET.  As  often
  901.  
  902.                              - 15 -
  903.  
  904.  
  905. IEN 187                              Bolt Beranek and Newman Inc.
  906.                                                     Eric C. Rosen
  907.  
  908.  
  909. seems  to happen in practice, the sites that are stubs seem to be
  910.  
  911. attached by the least reliable lines, so that partitions are  not
  912.  
  913. infrequent.   At any rate, there will probably be networks in the
  914.  
  915. internet that partition more frequently than  the  ARPANET  does.
  916.  
  917. Internet  protocols  must detect and react to network partitions,
  918.  
  919. instead of simply disregarding them as  "too  unlikely  to  worry
  920.  
  921. about." )
  922.  
  923.  
  924.      In  the special case where the Pathway between some Host and
  925.  
  926. some Switch is  the  ARPANET,  the  ARPANET  itself  can  provide
  927.  
  928. information  to  the  Host  telling  it  whether  the  Switch  is
  929.  
  930. reachable.  If the Switch is not reachable, and a  Host  attempts
  931.  
  932. to  send  an  ordinary data packet to it, the ARPANET will inform
  933.  
  934. the Host whether or not that packet was delivered,  and  if  not,
  935.  
  936. why  not.   Unfortunately,  the  current ARPANET does not provide
  937.  
  938. this information in response  to  datagrams.   However,  we  have
  939.  
  940. already  seen the need to provide such information in the case of
  941.  
  942. logically  addressed  datagrams  (see  IEN  183),  and  plan   to
  943.  
  944. implement  a  scheme for doing so.  An ARPANET Host which is also
  945.  
  946. an internet Host  can  implement  a  low  level  Pathway  up/down
  947.  
  948. protocol  simply  by paying attention to the 1822 replies that it
  949.  
  950. receives from  the  ARPANET.   There  are  hosts  which  seem  to
  951.  
  952. disregard these 1822 control messages, and which seem to continue
  953.  
  954. to  send  messages  for  unreachable  hosts into the ARPANET.  Of
  955.  
  956. course, this is a senseless waste of resources which can severely
  957.  
  958. degrade performance.  Indeed, it may look to an end-user, or even
  959.  
  960.                              - 16 -
  961.  
  962.  
  963. IEN 187                              Bolt Beranek and Newman Inc.
  964.                                                     Eric C. Rosen
  965.  
  966.  
  967. a gateway implementer, as though the  ARPANET  is  throwing  away
  968.  
  969. packets  for  no  reason,  when the real problem is that the host
  970.  
  971. software cannot  respond  adequately  to  exceptional  conditions
  972.  
  973. reported to it by the network.
  974.  
  975.  
  976.      We  have  spoken  of  the  need for Host and Switch to run a
  977.  
  978. higher level up/down protocol, to take account of the  conditions
  979.  
  980. when  one  of them seems reachable to the network, but still will
  981.  
  982. not  perform  adequately  when   another   entity   attempts   to
  983.  
  984. communicate  with  it.   Switch  and  Host must run some protocol
  985.  
  986. together which enables each to validate the proper performance of
  987.  
  988. the other.  The Catenet Monitoring  and  Control  System  (CMCC),
  989.  
  990. currently  running on ISIE, runs a protocol of this sort with the
  991.  
  992. gateways.  The CMCC sends a special datagram every minute to each
  993.  
  994. gateway, and expects to receive an acknowledgment (or  echo)  for
  995.  
  996. this  special  datagram  back  from  the  gateway.   After  three
  997.  
  998. consecutive minutes of not receiving the echo,  the  CMCC  infers
  999.  
  1000. that  the  gateway  cannot  be reached.  After receiving a single
  1001.  
  1002. echo, the CMCC infers that the gateway can be reached.  (Gateways
  1003.  
  1004. run a similar protocol with  their  "neighboring  gateways".)   A
  1005.  
  1006. Pathway  up/down  protocol which does not rely on the intervening
  1007.  
  1008. network to  furnish  the  information  would  certainly  have  to
  1009.  
  1010. involve  some  such  exchange of packets between the Host and the
  1011.  
  1012. Switch, but it would have to be rather  more  complex  than  this
  1013.  
  1014. one.   One  of  the  problems  with  this  protocol is that it is
  1015.  
  1016. incapable of detecting outages of less than three minutes.   This
  1017.  
  1018.                              - 17 -
  1019.  
  1020.  
  1021. IEN 187                              Bolt Beranek and Newman Inc.
  1022.                                                     Eric C. Rosen
  1023.  
  1024.  
  1025. may  be  suitable  for  the CMCC's purposes, but is not generally
  1026.  
  1027. suitable for a Host which wants to know which  source  Switch  to
  1028.  
  1029. send  its traffic to.  We would not want some Host to spend three
  1030.  
  1031. full minutes sending data to a Switch which  cannot  be  reached;
  1032.  
  1033. the  effect  of that could be many thousands of bits of data down
  1034.  
  1035. the drain.  (Of course, higher level  protocols  like  TCP  would
  1036.  
  1037. probably  recover  the  lost  data  eventually through the use of
  1038.  
  1039. Host-Host retransmissions, but that involves both a severe  drain
  1040.  
  1041. on  the resources of the Host, which ought to be avoided whenever
  1042.  
  1043. possible, and a severe  degradation  in  delay  and  throughput.)
  1044.  
  1045. Another  problem  with  this  particular protocol is that it uses
  1046.  
  1047. datagrams, which are inherently unreliable, and as a result,  the
  1048.  
  1049. inference  drawn  by  the CMCC is unreliable.  From the fact that
  1050.  
  1051. three datagrams fail to get through, it is quite a  big  jump  to
  1052.  
  1053. infer that no traffic at all can get through.  Another problem is
  1054.  
  1055. the  periodicity  of the test packets.  If they get in phase with
  1056.  
  1057. something else which may be going on  in  the  network,  spurious
  1058.  
  1059. results may be produced.
  1060.  
  1061.  
  1062.      The  design  of  a  Pathway  up/down  protocol  must also be
  1063.  
  1064. sensitive to the fact that some component network  of  a  Pathway
  1065.  
  1066. may be passing only certain types of packets and not others.  For
  1067.  
  1068. example,  at  times  of heavy usage, certain networks may only be
  1069.  
  1070. able to handle packets  of  high  priority,  and  lower  priority
  1071.  
  1072. packets  may either be refused by that net (at its access point),
  1073.  
  1074. or, even worse, discarded internally by the net with no feedback.
  1075.  
  1076.                              - 18 -
  1077.  
  1078.  
  1079. IEN 187                              Bolt Beranek and Newman Inc.
  1080.                                                     Eric C. Rosen
  1081.  
  1082.  
  1083. The Pathway up/down protocol must be sensitive to this, and  will
  1084.  
  1085. have to indicate that the Pathway is only "up" to certain classes
  1086.  
  1087. of  traffic.   If  a  Pathway is really a Network Structure which
  1088.  
  1089. will inform its Hosts  when  it  cannot  accept  certain  traffic
  1090.  
  1091. types,  then  this  information  can be fed back into the up/down
  1092.  
  1093. protocol.  (Note however that this might be very difficult to  do
  1094.  
  1095. if  the  Pathway  consists  of  not  a  single network, but of an
  1096.  
  1097. internet).  Alternatively, a Host may have to rely on its  higher
  1098.  
  1099. level  Pathway up/down protocol to determine, for several classes
  1100.  
  1101. of traffic, whether the Pathway is up to members of  that  class.
  1102.  
  1103. Apart  from  the  inherent  difficulty  of  doing this, it may be
  1104.  
  1105. difficult to map the  traffic  classes  that  a  given  component
  1106.  
  1107. network distinguishes into traffic classes that are meaningful to
  1108.  
  1109. a Host, or even to the Switches of the internet.  Yet we wouldn't
  1110.  
  1111. want  traffic  to  be  sent into a network which is not accepting
  1112.  
  1113. that  particular  kind  of  traffic,  especially  if  there   are
  1114.  
  1115. alternative  Pathways  which  would  be  willing  to  accept that
  1116.  
  1117. traffic.
  1118.  
  1119.  
  1120.      Many of these considerations suggest that the  higher  level
  1121.  
  1122. up/down  protocols  could  turn  out  to  be rather intricate and
  1123.  
  1124. expensive.  Remember that a gateway  may  have  many  many  hosts
  1125.  
  1126. "homed"  to it, and must be able to determine, for each and every
  1127.  
  1128. one of these hosts, whether communication with  it  is  possible.
  1129.  
  1130. Yet  it probably is not feasible to suppose that each gateway can
  1131.  
  1132. be continuously running an up/down protocol with  each  potential
  1133.  
  1134.                              - 19 -
  1135.  
  1136.  
  1137. IEN 187                              Bolt Beranek and Newman Inc.
  1138.                                                     Eric C. Rosen
  1139.  
  1140.  
  1141. host,  and  still  have time left to handle its ordinary traffic.
  1142.  
  1143. This suggests that the primary up/down determination be made from
  1144.  
  1145. the low-level protocol, i.e., that the Switches  should  rely  on
  1146.  
  1147. the  networks  underlying  the  Pathways to inform them whether a
  1148.  
  1149. given Host is up or down, and the Hosts should similarly rely  on
  1150.  
  1151. the   networks  underlying  the  Pathways  to  pass  them  status
  1152.  
  1153. information about the gateways.  It would be best if  the  higher
  1154.  
  1155. level up/down protocol only needed to be run intermittently, as a
  1156.  
  1157. check   on   the   reliability   of  the  lower  level  protocol.
  1158.  
  1159. Unfortunately, the use of low  level  up/down  protocols  is  not
  1160.  
  1161. always  possible.  Many networks, unlike the ARPANET, do not even
  1162.  
  1163. gather any information about the status of their hosts, and hence
  1164.  
  1165. cannot inform a source Host that it is attempting to send data to
  1166.  
  1167. a destination Host which is not reachable.  (SATNET is an example
  1168.  
  1169. of a network that does not pass "destination dead"  information.)
  1170.  
  1171. In  the  case where a particular Host-Switch Pathway is itself an
  1172.  
  1173. internet, the  problem  is  even  worse.   Unless  the  component
  1174.  
  1175. networks  of  that internet can be made to cooperate in obtaining
  1176.  
  1177. RELIABLE up/down information and passing it back  to  the  source
  1178.  
  1179. Host,  it  will  be  very  hard for a Host to make any reasonable
  1180.  
  1181. determination as to whether a particular Switch is reachable.  We
  1182.  
  1183. would strongly recommend the incorporation of low  level  up/down
  1184.  
  1185. protocols in ALL component networks of the internet.
  1186.  
  1187.  
  1188.      There   is  another  important  problem  in  having  a  Host
  1189.  
  1190. determine which of its potential source Switches on the  internet
  1191.  
  1192.                              - 20 -
  1193.  
  1194.  
  1195. IEN 187                              Bolt Beranek and Newman Inc.
  1196.                                                     Eric C. Rosen
  1197.  
  1198.  
  1199. are  up  and which are down.  In order to run a protocol with the
  1200.  
  1201. Switch, or even to  query  the  lower  level  network  about  the
  1202.  
  1203. Switch,  the  Host  must have some way of identifying the Switch.
  1204.  
  1205. It is not so difficult for a Host on the ARPANET to identify  the
  1206.  
  1207. IMPs  that  it is directly connected to, since it is quite simple
  1208.  
  1209. to devise a protocol by which a Host can send a message down each
  1210.  
  1211. of its access lines, asking who is  on  the  other  end.   It  is
  1212.  
  1213. rather more difficult for a Host to find out which gateways it is
  1214.  
  1215. homed  to (i.e., which gateways are on a common network with it).
  1216.  
  1217. There is no easy way for an ARPANET Host to find out which  other
  1218.  
  1219. ARPANET   hosts  are  Catenet  gateways.   There  is  no  "direct
  1220.  
  1221. connection" at which to direct protocol messages.  In the current
  1222.  
  1223. Catenet, hosts have to  know  in  advance  how  to  identify  the
  1224.  
  1225. Catenet  gateways  on  their networks (although there are certain
  1226.  
  1227. restricted circumstances under which a host can obtain  the  name
  1228.  
  1229. of  another gateway from a gateway about which it already knows).
  1230.  
  1231. Yet it does not seem like a good idea to require a Host to  know,
  1232.  
  1233. a  priori,  which  other  Hosts  on its network are also internet
  1234.  
  1235. Switches.  This makes  it  difficult  to  enable  Hosts  to  take
  1236.  
  1237. advantage  of newly installed gateways, without making changes by
  1238.  
  1239. hand to tables in the Hosts  (a  procedure  which  could  require
  1240.  
  1241. weeks  to take effect).  There is a rather attractive solution to
  1242.  
  1243. this problem.  If each component  network  in  the  internet  can
  1244.  
  1245. determine  for  itself  which  of  its  Hosts  are  also internet
  1246.  
  1247. Switches (gateways),  then  the  Switches  of  that  network  can
  1248.  
  1249.  
  1250.                              - 21 -
  1251.  
  1252.  
  1253. IEN 187                              Bolt Beranek and Newman Inc.
  1254.                                                     Eric C. Rosen
  1255.  
  1256.  
  1257. provide  that  information  to the Hosts.  This would require the
  1258.  
  1259. existence of a protocol which the gateways run with the  Switches
  1260.  
  1261. of  the  individual  component  networks,  by  means of which the
  1262.  
  1263. gateways declare themselves  to  be  gateways.   Each  individual
  1264.  
  1265. network  would  also  have  to  have  some  internal protocol for
  1266.  
  1267. disseminating this information to other Hosts,  and  for  keeping
  1268.  
  1269. this  information  up  to  date.   If  the  network  allows GROUP
  1270.  
  1271. ADDRESSING, further advantages are possible.  The  network  could
  1272.  
  1273. maintain  a group address (called, say, "Catenet Gateways") which
  1274.  
  1275. varies dynamically as  gateways  enter  and  leave  the  network.
  1276.  
  1277. Hosts could find out which gateways are reachable over particular
  1278.  
  1279. network  access lines by sending some sort of protocol message to
  1280.  
  1281. the group address, and waiting to see who replies.   Hosts  would
  1282.  
  1283. then  not  have to have any a priori knowledge of the gateways on
  1284.  
  1285. their home networks.
  1286.  
  1287.  
  1288.      One very important though often neglected aspect of  up/down
  1289.  
  1290. protocols is the way in which the up/down protocol interacts with
  1291.  
  1292. the  ability  to  perform  adequate  maintenance  of  the Network
  1293.  
  1294. Structure.  It is  tempting  to  think  that  a  Pathway  up/down
  1295.  
  1296. protocol  ought to declare a Pathway "down" only if it is totally
  1297.  
  1298. dead or otherwise totally  unusable.   But  in  fact,  a  pathway
  1299.  
  1300. should  be  declared  down before it becomes totally dead, if its
  1301.  
  1302. packet "non-delivery rate" exceeds a certain threshold.  (We  use
  1303.  
  1304. the  term "non-delivery rate" where the term "error rate" is more
  1305.  
  1306. commonly used.  We are trying to emphasize that it  is  important
  1307.  
  1308.                              - 22 -
  1309.  
  1310.  
  1311. IEN 187                              Bolt Beranek and Newman Inc.
  1312.                                                     Eric C. Rosen
  1313.  
  1314.  
  1315. to  detect  not only errors, in the sense of checksum errors, but
  1316.  
  1317. rather any circumstances, including but not limited  to  checksum
  1318.  
  1319. errors, which prevent the proper delivery of packets.)  There are
  1320.  
  1321. two reasons for this:
  1322.  
  1323.  
  1324.      1) The existence  of  a  non-zero  non-delivery  rate  on  a
  1325.  
  1326.         Pathway  implies that some packets placed on that Pathway
  1327.  
  1328.         will not make it through  to  the  other  end.   In  most
  1329.  
  1330.         applications, these packets will have to be retransmitted
  1331.  
  1332.         at some higher level of protocol, or else by the end user
  1333.  
  1334.         himself  (packetized  speech is one of the few exceptions
  1335.  
  1336.         to this).  As the number  of  retransmissions  increases,
  1337.  
  1338.         the  delay  also increases, and the throughput decreases.
  1339.  
  1340.         So when the non-delivery rate reaches  a  certain  point,
  1341.  
  1342.         the  Pathway  should be removed from service, in order to
  1343.  
  1344.         improve delay and throughput.  Of  course,  this  assumes
  1345.  
  1346.         that  an  alternate  Pathway  is  available  with a lower
  1347.  
  1348.         non-delivery  rate.   Also,  other  things  being  equal,
  1349.  
  1350.         removing  bandwidth  from  a  Network Structure will also
  1351.  
  1352.         tend to increase  delay  and  reduce  throughput,  so  we
  1353.  
  1354.         really  want  the up/down protocol to pick out the proper
  1355.  
  1356.         cross-over point.
  1357.  
  1358.  
  1359.      2) It is often better to fix a Pathway at the first sign  of
  1360.  
  1361.         trouble  than  to  wait  for  it  to  fail  totally.  One
  1362.  
  1363.         implication of this is that the up/down  protocol  should
  1364.  
  1365.  
  1366.                              - 23 -
  1367.  
  1368.  
  1369. IEN 187                              Bolt Beranek and Newman Inc.
  1370.                                                     Eric C. Rosen
  1371.  
  1372.  
  1373.         perform  equally  well  whether  or  not  the  Pathway is
  1374.  
  1375.         heavily loaded with traffic.  We would not want to use  a
  1376.  
  1377.         protocol  which  made  its determination solely by making
  1378.  
  1379.         measurements of user traffic, since that  protocol  would
  1380.  
  1381.         not  function  well  during  periods when user traffic is
  1382.  
  1383.         very light.  That is,  a  faulty  Pathway  with  no  user
  1384.  
  1385.         traffic would not be detected.  Yet if repair work has to
  1386.  
  1387.         be  done  on  a  Pathway,  we would most like to find out
  1388.  
  1389.         about it during lightly loaded hours, so that a  fix  can
  1390.  
  1391.         be  effected with minimal disruption, possibly before the
  1392.  
  1393.         heavily loaded hours begin.
  1394.  
  1395.  
  1396.      Another  important  characteristic  for  a  Pathway  up/down
  1397.  
  1398. protocol  to  have  is the ability to determine the nature of the
  1399.  
  1400. Pathway "outage".  This is quite important for  fault  isolation,
  1401.  
  1402. but  is easy for a host software person to overlook, since he may
  1403.  
  1404. not be aware of such issues.  If a Host cannot get its packets to
  1405.  
  1406. a Switch over a certain Pathway, it  will  want  to  regard  that
  1407.  
  1408. Pathway as down, and will want to use an alternate Pathway.  From
  1409.  
  1410. the Host perspective, it doesn't care whether the reason it can't
  1411.  
  1412. use  the Pathway is because of a network partition, or because of
  1413.  
  1414. network congestion, or because of some other reason.  However, if
  1415.  
  1416. the Host personnel want  to  be  able  to  call  up  the  Pathway
  1417.  
  1418. personnel  and request that the problem be fixed, it's not enough
  1419.  
  1420. to say, "Your network isn't  working;  call  me  back  when  it's
  1421.  
  1422. fixed."   The  more  information the Pathway up/down protocol can
  1423.  
  1424.                              - 24 -
  1425.  
  1426.  
  1427. IEN 187                              Bolt Beranek and Newman Inc.
  1428.                                                     Eric C. Rosen
  1429.  
  1430.  
  1431. gather, the quicker a fix can be effected.  In the case where the
  1432.  
  1433. Pathway is the  ARPANET,  quite  a  bit  of  information  can  be
  1434.  
  1435. gathered  from  proper  instrumentation  of  the 1822 module, and
  1436.  
  1437. proper attention by the host software to the 1822 replies;   this
  1438.  
  1439. will be discussed further in section 2.6.
  1440.  
  1441.  
  1442.      The design of the ARPANET's line up/down protocol might be a
  1443.  
  1444. good  model for the design of a general Pathway up/down protocol.
  1445.  
  1446. The design of the ARPANET protocol was based upon a  mathematical
  1447.  
  1448. analysis  of the probabilistic error characteristics of telephone
  1449.  
  1450. circuits, and the protocol is intended to bring a line down  when
  1451.  
  1452. and  only  when its error rate exceeds a threshold.  However, the
  1453.  
  1454. error  characteristics  of  Pathways   in   general   (i.e.,   of
  1455.  
  1456. packet-switching  networks)  are  not well understood at all, and
  1457.  
  1458. there is no similar mathematical analysis that we can appeal  to.
  1459.  
  1460. At present, we can offer no ready answer to the question of how a
  1461.  
  1462. Host  can  tell  which  of  several  possible  source Switches is
  1463.  
  1464. reachable, if  the  Switches  are  accessed  via  a  network  (or
  1465.  
  1466. sequence of networks) which will not even inform the Host whether
  1467.  
  1468. or  not  its  traffic  even gets delivered.  This is an important
  1469.  
  1470. question which will require  further  thought,  and  considerable
  1471.  
  1472. experimentation.
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.                              - 25 -
  1483.  
  1484.  
  1485. IEN 187                              Bolt Beranek and Newman Inc.
  1486.                                                     Eric C. Rosen
  1487.  
  1488.  
  1489. 2.2  Choosing a Source Switch
  1490.  
  1491.  
  1492.      Once  a  Host  has  determined  which source Switches it can
  1493.  
  1494. reach over which of its interfaces, it  still  has  to  determine
  1495.  
  1496. which  one  to use for sending some particular packet (unless the
  1497.  
  1498. Host is "lucky" enough to find out that only one source Switch is
  1499.  
  1500. reachable).  Making the proper choice  can  be  quite  important,
  1501.  
  1502. since  the  performance  which  the  Host  gets  may vary greatly
  1503.  
  1504. depending upon which source Switch it  selects.   That  is,  some
  1505.  
  1506. source  Switch  might be much closer to the destination, in terms
  1507.  
  1508. of delay, than another.  It then  might  be  quite  important  to
  1509.  
  1510. choose  the  proper  one.   To  make  things a bit more concrete,
  1511.  
  1512. consider the case of a Host which  is  multi-homed  (via  several
  1513.  
  1514. distinct  1822  links) to several ARPANET IMPs, and whose traffic
  1515.  
  1516. can be handled entirely within the ARPANET.   There  are  several
  1517.  
  1518. things  a  host  might  want to take into account in choosing the
  1519.  
  1520. best source IMP to use for a particular packet, including:
  1521.  
  1522.  
  1523.      1) The loading on the 1822  access  line  to  each  possible
  1524.  
  1525.         source IMP.
  1526.  
  1527.  
  1528.      2) The distance between each source IMP and the  destination
  1529.  
  1530.         Host, for some notion of "distance."
  1531.  
  1532.  
  1533.      The  first  of  these  two  quantities is relatively easy to
  1534.  
  1535. obtain, since all the Host need do is monitor its own 1822 lines;
  1536.  
  1537. it should  be  possible  to  devise  a  monitoring  scheme  which
  1538.  
  1539.  
  1540.                              - 26 -
  1541.  
  1542.  
  1543. IEN 187                              Bolt Beranek and Newman Inc.
  1544.                                                     Eric C. Rosen
  1545.  
  1546.  
  1547. indicates  which  of the 1822 lines is providing the best service
  1548.  
  1549. to its  IMP,  perhaps  simply  by  measuring  the  queuing  delay
  1550.  
  1551. experienced  in  the Host by messages queued for that line.  (Any
  1552.  
  1553. such measurement would have to take  into  account  some  of  the
  1554.  
  1555. niceties  of  the  1822 protocol, though.)  Obtaining information
  1556.  
  1557. about the second quantity is more difficult.  The Host might  try
  1558.  
  1559. to  keep some measurement of round-trip delay (delay until a RFNM
  1560.  
  1561. is received) between itself and each destination Host.   However,
  1562.  
  1563. in order to do this, some traffic for each destination Host would
  1564.  
  1565. have to be sent over each access line, so that the delay could be
  1566.  
  1567. measured.   This  means  that  some traffic has to be sent over a
  1568.  
  1569. long delay path, simply in order to determine that that is a long
  1570.  
  1571. delay path.  A simpler scheme might be for the Host to get  delay
  1572.  
  1573. information from the IMP.  A Host could ask each potential source
  1574.  
  1575. IMP  what  its  delay  to the destination Host is.  By using this
  1576.  
  1577. information, plus the information it gathers  locally  about  the
  1578.  
  1579. loading  of  its  access  lines,  the  Host could determine which
  1580.  
  1581. source IMP provides the shortest path to the destination.
  1582.  
  1583.  
  1584.      This would require that we define a protocol by which a Host
  1585.  
  1586. can ask the IMPs to which it is homed to provide their delays  to
  1587.  
  1588. a   destination   Host.   The  Host  could  make  these  requests
  1589.  
  1590. periodically, and then change its selection  of  source  IMPs  as
  1591.  
  1592. required  in order to react to changes in delay.  There are a few
  1593.  
  1594. subtle protocol issues to be considered here, though.   We  would
  1595.  
  1596. have  to  make  sure that a Host cannot beat a Switch to death by
  1597.  
  1598.                              - 27 -
  1599.  
  1600.  
  1601. IEN 187                              Bolt Beranek and Newman Inc.
  1602.                                                     Eric C. Rosen
  1603.  
  1604.  
  1605. constantly asking it what its delays are; probably we would  have
  1606.  
  1607. to  give  the Switch the option of not replying to these requests
  1608.  
  1609. if it is too busy with other things (like ordinary data traffic).
  1610.  
  1611. A bigger problem lies in the assumption that  the  Switches  will
  1612.  
  1613. even  have  this  data to provide.  The routing algorithm used by
  1614.  
  1615. the ARPANET IMPs does, in fact, provide each IMP with a value  of
  1616.  
  1617. delay,  in milliseconds, to each other IMP in the network.  There
  1618.  
  1619. is no reason why this information could not be fed  back  to  the
  1620.  
  1621. hosts  on  request.  Note, however, that while a source IMP knows
  1622.  
  1623. its delay to each possible destination IMP, it does not know  its
  1624.  
  1625. delay  to  each  potential  destination  HOST  over each possible
  1626.  
  1627. access line to that Host, since the routing  algorithm  does  not
  1628.  
  1629. maintain  measurements of delay from an IMP to a locally attached
  1630.  
  1631. host.  Yet this latter delay might be quite significant.   Still,
  1632.  
  1633. the  information that the ARPANET IMPs could provide to the Hosts
  1634.  
  1635. should enable them to make a better choice than they  could  make
  1636.  
  1637. without this information.
  1638.  
  1639.  
  1640.      Another  problem  with this idea of having the Switches feed
  1641.  
  1642. back delay information to the  Hosts  is  the  proper  choice  of
  1643.  
  1644. units.  If a Host is going to take the delay information provided
  1645.  
  1646. by   the  network  and  then  add  some  locally  measured  delay
  1647.  
  1648. information to it, it is important for  the  Host  to  know  what
  1649.  
  1650. units the network is using to measure delay.  Yet we also have to
  1651.  
  1652. ensure  that  the  network developers and maintainers are free to
  1653.  
  1654. change the way in which the network does  measurements,  and  the
  1655.  
  1656.                              - 28 -
  1657.  
  1658.  
  1659. IEN 187                              Bolt Beranek and Newman Inc.
  1660.                                                     Eric C. Rosen
  1661.  
  1662.  
  1663. units  in  which  the  measurements are taken, WITHOUT NEEDING TO
  1664.  
  1665. COORDINATE SUCH CHANGES WITH ALL HOST ADMINISTRATIONS.  That  is,
  1666.  
  1667. we  don't  want  further  development of the network, and further
  1668.  
  1669. refinements in the way  network  measurements  are  done,  to  be
  1670.  
  1671. overly constrained by the fact that the Hosts demand measurements
  1672.  
  1673. in  a  certain  unit.   We also want to ensure that host software
  1674.  
  1675. implementations are not invalidated by a decision to  change  the
  1676.  
  1677. units  that  the  network uses for its internal measurements.  So
  1678.  
  1679. the protocol would have to enable the Switch  to  tell  the  Host
  1680.  
  1681. what  units  it  is  providing;  the  Host  would  then  make any
  1682.  
  1683. necessary conversions.  (Alternatively, the Host could  tell  the
  1684.  
  1685. Switch  what  units  it  wants,  and  the  Switch  could  do  the
  1686.  
  1687. conversion before sending the information to the Host.)
  1688.  
  1689.  
  1690.      In  the  internet  environment,  the   situation   is   more
  1691.  
  1692. complicated.   An  ARPANET  Host  which  is also an internet Host
  1693.  
  1694. would have to (a) figure out its delay  to  each  of  its  source
  1695.  
  1696. IMPs,  (b)  query  each  source  IMP for its delay to each source
  1697.  
  1698. gateway, and (c) query each source gateway  about  its  delay  to
  1699.  
  1700. each  destination.  There is no straightforward way to gather the
  1701.  
  1702. rest of the needed delay information, however, namely  the  delay
  1703.  
  1704. from  the  destination  gateway to the destination Host.  In more
  1705.  
  1706. complex Network Structures,  with  internets  nested  on  top  of
  1707.  
  1708. internets,  this  problem  becomes increasingly more complex.  It
  1709.  
  1710. seems  that  the  only  really  reliable  way,   and   the   most
  1711.  
  1712. straightforward  way,  for  the source Host to gather information
  1713.  
  1714.                              - 29 -
  1715.  
  1716.  
  1717. IEN 187                              Bolt Beranek and Newman Inc.
  1718.                                                     Eric C. Rosen
  1719.  
  1720.  
  1721. about the delays via various source  Switches  to  a  destination
  1722.  
  1723. Host,  is  for  it  to  do  the measurements itself.  This is the
  1724.  
  1725. recommended solution.  Delay  information  should  also  be  made
  1726.  
  1727. available  from  the component networks for Hosts which cannot do
  1728.  
  1729. this, but it should be understood that those hosts cannot  expect
  1730.  
  1731. to get as good a quality of service as the hosts which go to more
  1732.  
  1733. trouble to do their own measurements.
  1734.  
  1735.  
  1736.  
  1737. 2.3  Type of Service
  1738.  
  1739.  
  1740.      One  very  important  piece  of information that a Host must
  1741.  
  1742. specify to the source Switch through the Network Access  Protocol
  1743.  
  1744. is the "type of service" desired.  To quote from the DoD standard
  1745.  
  1746. Internet  Protocol  (IP)  specification  [1, p. 15], "The Type of
  1747.  
  1748. Service is used to indicate the quality of the  service  desired;
  1749.  
  1750. this  may  be thought of as selecting among Interactive, Bulk, or
  1751.  
  1752. Real Time, for example."  This seems to  make  sense,  since  one
  1753.  
  1754. does  have  the feeling that different types of applications will
  1755.  
  1756. fall  into  different  categories,  and  information  about   the
  1757.  
  1758. categories may help the Switches of the Network Structure through
  1759.  
  1760. which  the  data is moving decide how best to treat it.  However,
  1761.  
  1762. choosing just the right set of categories of service is  quite  a
  1763.  
  1764. complex   matter.   For  example,  both  a  terminal  user  of  a
  1765.  
  1766. time-sharing system, and a user of a query-response system  (like
  1767.  
  1768. an  automated teller) fall under the rubric of "interactive", but
  1769.  
  1770. that doesn't mean that the service  requirements  are  the  same.
  1771.  
  1772.                              - 30 -
  1773.  
  1774.  
  1775. IEN 187                              Bolt Beranek and Newman Inc.
  1776.                                                     Eric C. Rosen
  1777.  
  1778.  
  1779. Both  Remote-Job-Entry and File Transfer fall under the rubric of
  1780.  
  1781. "bulk",  but  it  is  not  obvious  that  they  have   the   same
  1782.  
  1783. requirements.   Both  real-time  process  control  and packetized
  1784.  
  1785. voice fall into the category of "Real Time", but the requirements
  1786.  
  1787. of these two applications seem to be very different.  A very real
  1788.  
  1789. issue, which has not yet been given  adequate  consideration,  is
  1790.  
  1791. the  question  of  just  how  many categories of application type
  1792.  
  1793. there really should be, and just what the implications of putting
  1794.  
  1795. a packet into one of these categories ought to be.  As we go  on,
  1796.  
  1797. we  will  see  a  number  of  problems that arise from failure to
  1798.  
  1799. carefully consider this issue.
  1800.  
  1801.  
  1802.      It is rather difficult to find examples  of  Network  Access
  1803.  
  1804. Protocols  which  have  really  useful class-of-service selection
  1805.  
  1806. mechanisms.  The 1822 protocol allows the  user  to  select  from
  1807.  
  1808. among  two  priorities;  it allows the choice of single-packet or
  1809.  
  1810. multi-packet messages; it allows the choice between "raw packets"
  1811.  
  1812. and "controlled  packets."  It  is  up  to  some  user  (or  more
  1813.  
  1814. realistically,  up to some host software implementer who may have
  1815.  
  1816. only a vague and limited understanding of the applications  which
  1817.  
  1818. his software will serve, and of the network that he is accessing)
  1819.  
  1820. to  map his application characteristics onto these three choices.
  1821.  
  1822. Unfortunately, it is doubtful that there is anyone outside of the
  1823.  
  1824. ARPANET  group  at  BBN  with  any  clear  understanding  of  the
  1825.  
  1826. implications  of  making the various choices.  The task of making
  1827.  
  1828. the optimum choice for some application is further complicated by
  1829.  
  1830.                              - 31 -
  1831.  
  1832.  
  1833. IEN 187                              Bolt Beranek and Newman Inc.
  1834.                                                     Eric C. Rosen
  1835.  
  1836.  
  1837. the fact that the effects of making the various  choices  can  be
  1838.  
  1839. very  dependent  on  the  network load.  For example, it is often
  1840.  
  1841. possible to get more throughput from single-packet messages  than
  1842.  
  1843. from  multi-packet messages.  This will happen if the destination
  1844.  
  1845. IMP has  several  different  source  Hosts  sending  multi-packet
  1846.  
  1847. messages  to  it,  but  is  short on buffer space (as many of the
  1848.  
  1849. ARPANET IMPs are), and if the multi-packet messages contain  only
  1850.  
  1851. two or three packets per message.  Not only is this sort of thing
  1852.  
  1853. very  difficult  for  an arbitrary user to understand (to a naive
  1854.  
  1855. network user, it must seem ridiculous), it  is  also  subject  to
  1856.  
  1857. change  without  notice.   Although  users can vary their service
  1858.  
  1859. significantly by sending optimum size  messages,  the  principles
  1860.  
  1861. governing  the  "optimum"  size  are  very obscure, and we cannot
  1862.  
  1863. really expect users to map their  application  requirements  onto
  1864.  
  1865. this network feature in any reasonable manner.
  1866.  
  1867.  
  1868.      A  similar  problem  arises with respect to the priority bit
  1869.  
  1870. that the 1822 protocol allows.  Basically, a priority packet will
  1871.  
  1872. get queued ahead of any non-priority packets on  the  queues  for
  1873.  
  1874. the  inter-IMP  links  and  on the queues for the IMP-Host access
  1875.  
  1876. lines.  However, priority packets receive no  special  preference
  1877.  
  1878. when  competing  with  non-priority packets for CPU cycles or for
  1879.  
  1880. buffer space.  Also, there is no notion at all in the ARPANET  of
  1881.  
  1882. refusing  to  accept  low priority packets because the network is
  1883.  
  1884. already too heavily loaded with high priority packets.   Although
  1885.  
  1886. someone  who  has  carefully studied the ARPANET might be able to
  1887.  
  1888.                              - 32 -
  1889.  
  1890.  
  1891. IEN 187                              Bolt Beranek and Newman Inc.
  1892.                                                     Eric C. Rosen
  1893.  
  1894.  
  1895. say what the effect of setting the priority  bit  is  under  some
  1896.  
  1897. particular  set  of  circumstances,  some  user  who is wondering
  1898.  
  1899. whether his application requirements are best served  by  setting
  1900.  
  1901. the  priority  bit  really has no way of answering that question.
  1902.  
  1903. The actual effect of the priority bit does not  fully  correspond
  1904.  
  1905. to  any  intuitive  notion  of priority that an arbitrary user is
  1906.  
  1907. likely to  have.   Another  problem:  although  it  is  presently
  1908.  
  1909. allowed,  it  is  not  really a good idea to let the users choose
  1910.  
  1911. whether to set the priority bit or not.  Fortunately, most  hosts
  1912.  
  1913. do  not  submit packets with the priority bit on.  It wouldn't be
  1914.  
  1915. terribly surprising, though, if some  host  software  implementer
  1916.  
  1917. decided  that  he  would always set the priority bit, in order to
  1918.  
  1919. get faster service.  Of course, overuse of the priority bit  just
  1920.  
  1921. means  that it will have no effect at all, and that seems to mean
  1922.  
  1923. that its use must be controlled in some way, and not simply  left
  1924.  
  1925. up to each user, as in the 1822 protocol.
  1926.  
  1927.  
  1928.      The  IP  offers  even  worse  problems  than  1822  in these
  1929.  
  1930. respects.  Like 1822, the IP does not really allow  the  user  to
  1931.  
  1932. classify  his  traffic according to application type.  Rather, it
  1933.  
  1934. forces him to pick one of  5  possible  precedence  values  (from
  1935.  
  1936. highest  to  lowest precedence, whatever that means, exactly), to
  1937.  
  1938. pick one of 4 reliability values (from most to  least  reliable),
  1939.  
  1940. to  indicate  whether  he  wants  his  data  to be stream data or
  1941.  
  1942. datagram data in component networks for which this distinction is
  1943.  
  1944. meaningful, to indicate whether he wants high or low  speed,  and
  1945.  
  1946.                              - 33 -
  1947.  
  1948.  
  1949. IEN 187                              Bolt Beranek and Newman Inc.
  1950.                                                     Eric C. Rosen
  1951.  
  1952.  
  1953. to   indicate  whether  speed  is  more  important  to  him  than
  1954.  
  1955. reliability is.  The idea here, apparently, is that any user  can
  1956.  
  1957. map   his   application   requirements   into   certain  abstract
  1958.  
  1959. properties, and the information which the IP passes from the Host
  1960.  
  1961. to the source Switch is  supposed  to  indicate  which  of  these
  1962.  
  1963. abstract  properties the user needs.  At each internet hop, these
  1964.  
  1965. abstract properties are  supposed  to  be  mapped  to  particular
  1966.  
  1967. properties  that  are meaningful to the network in question.  The
  1968.  
  1969. Pathway Access Protocol for that network would then  be  used  to
  1970.  
  1971. indicate   to   the  Switches  of  that  component  network  what
  1972.  
  1973. particular properties the data transfer should have  within  that
  1974.  
  1975. network.  In fact, the only apparent use of the "type of service"
  1976.  
  1977. information  in  the  internet Network Access Protocol (IP) is to
  1978.  
  1979. carry information to be passed to the individual  Pathway  Access
  1980.  
  1981. Protocols.
  1982.  
  1983.  
  1984.      This  all  sounds  reasonable  enough when considered in the
  1985.  
  1986. abstract, but it gives rise to a large number of vexing  problems
  1987.  
  1988. when  we  attempt to consider particular ways in which this "type
  1989.  
  1990. of service" information is to be  used.   Empirically,  it  seems
  1991.  
  1992. that  few current gateway implementations take any notice of this
  1993.  
  1994. information at all.  We suggest that the problem is not that  the
  1995.  
  1996. individual  implementers  have  not had time to write the code to
  1997.  
  1998. take account of this information, but rather that it is far  from
  1999.  
  2000. clear  how  this information should be handled, or even that this
  2001.  
  2002. information is really meaningful.  We  suggest  further  that  an
  2003.  
  2004.                              - 34 -
  2005.  
  2006.  
  2007. IEN 187                              Bolt Beranek and Newman Inc.
  2008.                                                     Eric C. Rosen
  2009.  
  2010.  
  2011. internet user would also have a great deal of difficulty deciding
  2012.  
  2013. how  to specify the "type of service" information in order to get
  2014.  
  2015. a specific quality of service needed by his application.
  2016.  
  2017.  
  2018.      Suppose a user needs the  maximum  possible  speed  for  his
  2019.  
  2020. application, so he uses IP to indicate that he values speed above
  2021.  
  2022. all  else.  What would the current Catenet do?  For concreteness,
  2023.  
  2024. suppose there is a choice of sending this user's data either  via
  2025.  
  2026. a  sequence of 4 low-delay terrestrial networks, or through three
  2027.  
  2028. satellite networks, each of which contains  two  satellite  hops.
  2029.  
  2030. The  current  implementation  of  the Catenet would send the data
  2031.  
  2032. through the three satellite networks.  However,  since  the  user
  2033.  
  2034. indicated  that  he  values speed above all else, he will get the
  2035.  
  2036. fastest service that each of the satellite networks can  provide!
  2037.  
  2038. Of  course, this may not be what the user will have expected when
  2039.  
  2040. he asked for speed, since the fastest service through a satellite
  2041.  
  2042. network is not fast.  A user may well wonder what  the  point  of
  2043.  
  2044. specifying  speed  is,  if  his  data  is  going to traverse some
  2045.  
  2046. sequence of satellite networks, even if a  much  faster  path  is
  2047.  
  2048. available.  Furthermore, it is not correct to assume, in general,
  2049.  
  2050. that  a  user  who  values  speed  will really want the speediest
  2051.  
  2052. service through every network.  If  traffic  must  go  through  a
  2053.  
  2054. satellite  network,  it  may  be  important to try to get one-hop
  2055.  
  2056. rather than two-hop delay, if this is possible.  Yet it  may  not
  2057.  
  2058. be  economical  to  also try to get the speediest service through
  2059.  
  2060. all terrestrial networks; the difference  between  high  and  low
  2061.  
  2062.                              - 35 -
  2063.  
  2064.  
  2065. IEN 187                              Bolt Beranek and Newman Inc.
  2066.                                                     Eric C. Rosen
  2067.  
  2068.  
  2069. speed  service  through  a  terrestrial  network might be "in the
  2070.  
  2071. noise", even when compared to  the  shortest  delay  through  the
  2072.  
  2073. satellite  network.  It is not impossible, or even unlikely, that
  2074.  
  2075. better overall service (or more cost-effective  service)  can  be
  2076.  
  2077. achieved  by  using  the  fastest  possible  service through some
  2078.  
  2079. networks, but less than the fastest through  others.   There  are
  2080.  
  2081. two  immediate  lessons  here.  First, the characteristics that a
  2082.  
  2083. user specifies in the Network Access Protocol  may  require  some
  2084.  
  2085. interaction  with  routing,  since the characteristics he desires
  2086.  
  2087. simply cannot be provided, in general,  by  sending  his  traffic
  2088.  
  2089. through a random series of networks, and then mapping information
  2090.  
  2091. he  specifies  in  the  Network  Access Protocol into information
  2092.  
  2093. carried in the individual Pathway Access Protocols.  Second, what
  2094.  
  2095. a user means intuitively by "speed" just may not  map  into  what
  2096.  
  2097. some  particular  component net means by "speed".  Once again, we
  2098.  
  2099. see  that  the   basic   problem   stems   from   the   differing
  2100.  
  2101. characteristics of the Pathways in the Network Structure.
  2102.  
  2103.  
  2104.      Another  peculiar  feature  of the IP is the mysterious "S/R
  2105.  
  2106. bit", which a user is supposed to  set  to  indicate  whether  he
  2107.  
  2108. prefers  speed  over  reliability,  or  vice  versa, should these
  2109.  
  2110. conflict.   One  unsuitable  aspect  of  this  is  the   apparent
  2111.  
  2112. assumption  that  it  even  makes sense to prefer either speed or
  2113.  
  2114. reliability over the other, without specifying more  detail.   It
  2115.  
  2116. is   easy  to  imagine  that  some  user  is  willing  to  accept
  2117.  
  2118. reliability of less than  100%  if  he  can  increase  his  speed
  2119.  
  2120.                              - 36 -
  2121.  
  2122.  
  2123. IEN 187                              Bolt Beranek and Newman Inc.
  2124.                                                     Eric C. Rosen
  2125.  
  2126.  
  2127. somewhat.   It  is  also  easy  to  imagine  that a user would be
  2128.  
  2129. willing to accept somewhat slower service if it gives him  higher
  2130.  
  2131. reliability.   But  there  will  always  be a range that the user
  2132.  
  2133. wants to stay within.  If his reliability must be moved  below  a
  2134.  
  2135. certain  threshold  in  order  to get more speed, he may not want
  2136.  
  2137. this, even if he would be willing to say that he prefers speed to
  2138.  
  2139. reliability.  Similarly, if his delay must  go  above  a  certain
  2140.  
  2141. threshold  to  gain  more reliability, he may not want this, even
  2142.  
  2143. if, when  talking  in  general  terms,  he  says  that  he  needs
  2144.  
  2145. reliability more than speed.  It really doesn't make any sense at
  2146.  
  2147. all  to try to map a particular application type into "speed over
  2148.  
  2149. reliability" or  "reliability  over  speed",  unless  ranges  and
  2150.  
  2151. thresholds  are  also  specified.  What this means in practice is
  2152.  
  2153. that a user will not be able to make a reasonable choice  of  how
  2154.  
  2155. to set this bit in the IP header; whatever he sets it to is bound
  2156.  
  2157. to produce results other than those he expects under some not too
  2158.  
  2159. uncommon set of circumstances.
  2160.  
  2161.  
  2162.      We  do  not  want to leave unquestioned the tacit assumption
  2163.  
  2164. that  speed  and  reliability  are  opposing  virtues,  so   that
  2165.  
  2166. increasing  one must be expected to decrease the other.  To quote
  2167.  
  2168. again from the IP spec, "typically networks invoke  more  complex
  2169.  
  2170. (and  delay  producing)  mechanisms  as  the need for reliability
  2171.  
  2172. increases" [1, p 23].  This reasoning  is  somewhat  superficial.
  2173.  
  2174. It  may be true that in some networks, the less reliable kinds of
  2175.  
  2176. service are speedier, but this is not invariably  the  case.   To
  2177.  
  2178.                              - 37 -
  2179.  
  2180.  
  2181. IEN 187                              Bolt Beranek and Newman Inc.
  2182.                                                     Eric C. Rosen
  2183.  
  2184.  
  2185. see  this,  consider  the  following  (fictitious) network.  This
  2186.  
  2187. network  allows  the  user  to  request  either   "reliable"   or
  2188.  
  2189. "unreliable" data transfer.  Reliable packets are controlled by a
  2190.  
  2191. set  of  protocols,  both at the end-end and hop-hop level, which
  2192.  
  2193. ensure delivery.  Unreliable packets are not under the control of
  2194.  
  2195. any such protocols.  Furthermore, reliable packets  go  ahead  of
  2196.  
  2197. unreliable  ones on all queues, in particular, the CPU queue.  In
  2198.  
  2199. addition, unreliable packets can be flushed from the net  at  any
  2200.  
  2201. time,  if  some resource they are using (such as buffer space) is
  2202.  
  2203. needed for a reliable packet.   These  latter  two  measures  are
  2204.  
  2205. needed  to  ensure that the net does not become so heavily loaded
  2206.  
  2207. with unreliable packets that there is no room  for  the  reliable
  2208.  
  2209. ones.   (It  would  not make much sense to advertise a "reliable"
  2210.  
  2211. service, and then to allow the unreliable packets to dominate the
  2212.  
  2213. network by using most of the network  resources.   If  unreliable
  2214.  
  2215. packets  could grab most of the resources, leaving the "reliable"
  2216.  
  2217. ones to scavenge for the left-over resources, then  it  would  be
  2218.  
  2219. virtually   inevitable   that   the   service   received  by  the
  2220.  
  2221. "unreliable" packets would appear,  to  the  users,  to  be  more
  2222.  
  2223. reliable than the service received by the "reliable" packets.  To
  2224.  
  2225. achieve a true dichotomy between reliable and unreliable service,
  2226.  
  2227. the  reliable packets must be given priority in all respects over
  2228.  
  2229. the unreliable ones.  We should also remember, by the  way,  that
  2230.  
  2231. although   many   protocols   combine  features  of  reliability,
  2232.  
  2233. sequentiality, error control, and flow control, these are not the
  2234.  
  2235.  
  2236.                              - 38 -
  2237.  
  2238.  
  2239. IEN 187                              Bolt Beranek and Newman Inc.
  2240.                                                     Eric C. Rosen
  2241.  
  2242.  
  2243. same, and there is no reason why a  network  might  not  offer  a
  2244.  
  2245. reliable  but  unsequenced service).  This sort of network design
  2246.  
  2247. seems quite reasonable, perhaps more reasonable than  the  design
  2248.  
  2249. of  any  existing  network.   It  would  allow  for a (presumably
  2250.  
  2251. inexpensive) class of service ("unreliable") which would be  able
  2252.  
  2253. to  use  only  those  network  resources  not  needed by the more
  2254.  
  2255. reliable (and expensive) class of packets, and  which  would  not
  2256.  
  2257. suffer  any additional delay due to the presence of the protocols
  2258.  
  2259. which would be needed to ensure reliability.  In such a  network,
  2260.  
  2261. unreliable packets might well experience less delay than reliable
  2262.  
  2263. ones,  WHEN  THE  NETWORK  IS  LIGHTLY LOADED; WHEN IT IS HEAVILY
  2264.  
  2265. LOADED, HOWEVER, RELIABLE PACKETS WOULD TEND  TO  EXPERIENCE  THE
  2266.  
  2267. SMALLER DELAY.  If this is the case, it is hard to see how a user
  2268.  
  2269. could  be  expected  to  make  a  reasonable choice of IP service
  2270.  
  2271. parameters at all.  He may know what his needs are,  but  we  can
  2272.  
  2273. hardly  expect  him  to know how to map his needs onto particular
  2274.  
  2275. aspects of the behavior of a particular network component  of  an
  2276.  
  2277. internet, especially when the behavior determined by that mapping
  2278.  
  2279. will  vary  dynamically  with the network loading, and hence with
  2280.  
  2281. the time of day.
  2282.  
  2283.  
  2284.      Two other peculiarities of the "type of service" feature  of
  2285.  
  2286. the  IP are worth mentioning.  First, there seems to be no notion
  2287.  
  2288. of the relation  between  speed  and  priority,  though  in  many
  2289.  
  2290. networks,  the  priority of a message is the major determinant of
  2291.  
  2292. its speed.  (There are, to be sure,  networks  which  attempt  to
  2293.  
  2294.                              - 39 -
  2295.  
  2296.  
  2297. IEN 187                              Bolt Beranek and Newman Inc.
  2298.                                                     Eric C. Rosen
  2299.  
  2300.  
  2301. treat  priority  solely as "acceptance class", differentiating it
  2302.  
  2303. completely from considerations of speed.  However, we know of  no
  2304.  
  2305. network  implementation  which  has  been  shown to differentiate
  2306.  
  2307. SUCCESSFULLY between these two concepts, and there is  reason  to
  2308.  
  2309. doubt  that  this differentiation is even possible in principle.)
  2310.  
  2311. Second, one of the choices to be made is whether to prefer stream
  2312.  
  2313. or datagram service.  This is a clear example of  something  that
  2314.  
  2315. is  not based on "abstract parameters of quality of service", but
  2316.  
  2317. rather on a particular feature of one or two particular networks.
  2318.  
  2319. Requesting stream service will NOT do what a user might expect it
  2320.  
  2321. to do, namely set up a stream  or  virtual  circuit  through  the
  2322.  
  2323. entire  internet.  This would require a lengthy connection set-up
  2324.  
  2325. procedure, involving reservations of resources in  the  gateways,
  2326.  
  2327. which resources are to be used only for specific connections.  If
  2328.  
  2329. we  are  really  serious  about providing stream service, this is
  2330.  
  2331. just  as  important  as  obtaining  stream  service  within   the
  2332.  
  2333. component  networks  serving  as  the  Pathways  of the internet.
  2334.  
  2335. Indeed, it is hard to  imagine  any  real  use  for  an  internet
  2336.  
  2337. "stream service" which treats packets as datagrams during most of
  2338.  
  2339. their  lifetime  in  the internet, and then treats them as stream
  2340.  
  2341. packets in one or two component networks.  It must be  remembered
  2342.  
  2343. that the sort of stream service provided by a network like SATNET
  2344.  
  2345. is  only  useful  to  a  user  if  his data appears at the SATNET
  2346.  
  2347. interface at fixed periods, synchronized with the  scheduling  of
  2348.  
  2349. the  stream  slots  on  the  satellite channel.  If the data must
  2350.  
  2351.  
  2352.                              - 40 -
  2353.  
  2354.  
  2355. IEN 187                              Bolt Beranek and Newman Inc.
  2356.                                                     Eric C. Rosen
  2357.  
  2358.  
  2359. first travel through several datagram  networks  before  reaching
  2360.  
  2361. SATNET,  IT  IS VIRTUALLY IMPOSSIBLE THAT THE DATA WILL ARRIVE AT
  2362.  
  2363. SATNET WITH THE PROPER PERIODICITY to allow it to make proper use
  2364.  
  2365. of the SATNET stream.  Now there are certain specific cases where
  2366.  
  2367. it might be possible to provide some sort of stream service,  say
  2368.  
  2369. if  some  data  is  going  from a local network through SATNET to
  2370.  
  2371. another local network and  thence  directly  to  the  destination
  2372.  
  2373. Host.   (Though even in this case, some sort of connection set-up
  2374.  
  2375. and reservation of resources in the gateways between  SATNET  and
  2376.  
  2377. the  local networks would probably be necessary.)  Note, however,
  2378.  
  2379. that if a  user  requests  this  type  of  service,  he  is  also
  2380.  
  2381. constraining  the types of routes his data can travel.  If SATNET
  2382.  
  2383. is not available, he might not want to use the internet at all at
  2384.  
  2385. that time.  Or he might be willing to  tolerate  a  less  optimal
  2386.  
  2387. route  ("half  a  loaf  is better than none"), but might not want
  2388.  
  2389. "stream service" if the less optimal route has to be used.  In no
  2390.  
  2391. case can a type of  service  like  "stream"  be  obtained  simply
  2392.  
  2393. through  the  mapping  of  "type of service" in the internet onto
  2394.  
  2395. "type of service" in the component networks.
  2396.  
  2397.  
  2398.      We do not want to have a Network Access Protocol  that  will
  2399.  
  2400. need  to  be infinitely expandable, so that the user can indicate
  2401.  
  2402. the type of service he wants in each particular network that  his
  2403.  
  2404. data  may  eventually  travel  through.   For  one  thing, as the
  2405.  
  2406. internet becomes larger, so that there  are  more  paths  between
  2407.  
  2408. each   possible  source  and  destination,  the  users  will  not
  2409.  
  2410.                              - 41 -
  2411.  
  2412.  
  2413. IEN 187                              Bolt Beranek and Newman Inc.
  2414.                                                     Eric C. Rosen
  2415.  
  2416.  
  2417. generally know what  set  of  networks  their  data  will  travel
  2418.  
  2419. through.   Since the number of component networks in the internet
  2420.  
  2421. may be continually increasing, and since we cannot anticipate  in
  2422.  
  2423. advance the features that each new network may offer, it does not
  2424.  
  2425. really  seem  reasonable to have to keep adding fields to the IP,
  2426.  
  2427. to account for particular characteristics of each  new  component
  2428.  
  2429. network.   Yet  this  seems inevitable with the current approach.
  2430.  
  2431. That is, we do not agree with the claim in the IP spec  that  the
  2432.  
  2433. type  of service field in the IP indicates "abstract parameters".
  2434.  
  2435. Rather, we think the type of service field has  been  constructed
  2436.  
  2437. with  certain  particular  networks  in mind, just those networks
  2438.  
  2439. which are currently in the Catenet, and that the various  service
  2440.  
  2441. fields  have  no  meaning  whatsoever  apart  from the particular
  2442.  
  2443. "suggested" mappings to protocol features  of  specific  networks
  2444.  
  2445. given   in   the  spec.   (And  since  these  mappings  are  only
  2446.  
  2447. "suggested", not required, one might wonder whether the  type  of
  2448.  
  2449. service  field  really  has any consistent meaning at all).  This
  2450.  
  2451. situation is perhaps tolerable in a research  environment,  where
  2452.  
  2453. most  of  the users of the internet are explicitly concerned with
  2454.  
  2455. issues of networking, and  willing  to  try  a  large  number  of
  2456.  
  2457. experiments  to  see  what  sort  of  service they get.  One must
  2458.  
  2459. remember, however, that in a truly operational  environment,  the
  2460.  
  2461. average  user will not be concerned at all about networking, will
  2462.  
  2463. not  know  anything  about  networking,  will  not   care   about
  2464.  
  2465. networking,  and will only want the network to appear transparent
  2466.  
  2467.  
  2468.                              - 42 -
  2469.  
  2470.  
  2471. IEN 187                              Bolt Beranek and Newman Inc.
  2472.                                                     Eric C. Rosen
  2473.  
  2474.  
  2475. to him.  In order for such a user to make successful use  of  the
  2476.  
  2477. type   of  service  field  in  a  Network  Access  Protocol,  the
  2478.  
  2479. parameters of the field must be meaningful to him.  If  they  are
  2480.  
  2481. only  meaningful  to network experts, the user will never be able
  2482.  
  2483. to figure out how best to set these parameters.
  2484.  
  2485.  
  2486.      Rather than providing a type of service specification  which
  2487.  
  2488. is  nothing  but  a  sort of "linear combination" of the types of
  2489.  
  2490. service provided by the component networks, the internet ought to
  2491.  
  2492. offer a  small,  specific  number  of  service  types  which  are
  2493.  
  2494. meaningful  at  the  application  level.   The possible values of
  2495.  
  2496. internet   service   type   might   be   "interactive   session,"
  2497.  
  2498. "transaction,"  "file transfer", "packetized speech," and perhaps
  2499.  
  2500. a few others.  The categories should be simple enough so that the
  2501.  
  2502. user can figure out which  category  his  particular  application
  2503.  
  2504. falls  into  without needing to know the details of the operation
  2505.  
  2506. of the internet.   The  Switches  of  the  internet  should  take
  2507.  
  2508. responsibility  for  sending the data on a route which is capable
  2509.  
  2510. of providing the requested type of service, and for  sending  the
  2511.  
  2512. data  through  component  networks of the internet in a way which
  2513.  
  2514. maximizes the possibility that the type of service requested will
  2515.  
  2516. actually be achieved.  Of course, in order to do  this,  we  must
  2517.  
  2518. first  answer  a  couple of hard questions, such as "Exactly what
  2519.  
  2520. characteristics  of  service  do  users  want  and   expect   for
  2521.  
  2522. particular  applications?",  and "What features must the internet
  2523.  
  2524. Switches have, and what  features  must  the  component  networks
  2525.  
  2526.                              - 43 -
  2527.  
  2528.  
  2529. IEN 187                              Bolt Beranek and Newman Inc.
  2530.                                                     Eric C. Rosen
  2531.  
  2532.  
  2533. have,   in   order   to   provide   service  with  the  necessary
  2534.  
  2535. characteristics?"   In  order  to  give  adequate  communications
  2536.  
  2537. service  in  an operational environment, however, these questions
  2538.  
  2539. must be given careful consideration by  internet  designers.   To
  2540.  
  2541. some  extent,  these questions are difficult research issues, and
  2542.  
  2543. answering them will require doing some systematic experimentation
  2544.  
  2545. and instrumentation in the internet.  The problem  is  hard,  but
  2546.  
  2547. unavoidable.    The   IP's   current   approach  seems  aimed  at
  2548.  
  2549. side-stepping these issues, since it places the  burden  entirely
  2550.  
  2551. on  the  user.   It  tends  to  give  users the illusion that, by
  2552.  
  2553. properly specifying the bit fields in the  IP  header,  they  can
  2554.  
  2555. tune  the  internet  to  provide  them  with the specific type of
  2556.  
  2557. service they find most desirable.   This  is,  however,  only  an
  2558.  
  2559. illusion.   The  perspective  taken by the current IP seems to be
  2560.  
  2561. not, "How should the internet be designed so as  to  provide  the
  2562.  
  2563. needed  characteristics  of  service  while  providing  a  simple
  2564.  
  2565. interface to the user?", but rather, "Taking the  current  design
  2566.  
  2567. of  the internet as a given, how can we give the user the ability
  2568.  
  2569. to  massage,  bend,  and  twist  it  so   as   to   get   service
  2570.  
  2571. characteristics  which  might  be  close  to what he wants?"  The
  2572.  
  2573. former perspective seems much more appropriate than  the  latter.
  2574.  
  2575.  
  2576.      Although  we  are  not  at  present  prepared  to  offer  an
  2577.  
  2578. alternative to IP, there are several lessons  we  would  like  to
  2579.  
  2580. draw from this discussion:
  2581.  
  2582.  
  2583.  
  2584.                              - 44 -
  2585.  
  2586.  
  2587. IEN 187                              Bolt Beranek and Newman Inc.
  2588.                                                     Eric C. Rosen
  2589.  
  2590.  
  2591.      1) While an internet Network  Access  Protocol  really  does
  2592.  
  2593.         need  to  contain  some field which indicates the desired
  2594.  
  2595.         type of service in a manner which is abstract  enough  to
  2596.  
  2597.         be  mapped  to particular protocol features of particular
  2598.  
  2599.         networks, the  proper  specification  of  a  sufficiently
  2600.  
  2601.         abstract  set  of  parameters  is  an  open and difficult
  2602.  
  2603.         research issue, but one which needs to be studied  if  an
  2604.  
  2605.         operational internet configuration is ever to give really
  2606.  
  2607.         adequate service to a relatively naive end-user.
  2608.  
  2609.  
  2610.      2) Providing the  requested  type  of  service  may  require
  2611.  
  2612.         cooperation  from  all  the Switches (perhaps through the
  2613.  
  2614.         routing algorithm), and involves more than  just  mapping
  2615.  
  2616.         fields  from  the internet Network Access Protocol to the
  2617.  
  2618.         particular  access  protocols  used  by   the   component
  2619.  
  2620.         networks.   If  the type of service requested by the user
  2621.  
  2622.         is to be consistently meaningful, then his  request  must
  2623.  
  2624.         be  given  UNIFORM  treatment  by  the internet Switches.
  2625.  
  2626.         Different gateways must not  be  allowed   to  treat  the
  2627.  
  2628.         request differently.
  2629.  
  2630.  
  2631. 2.4  Special Features
  2632.  
  2633.  
  2634.      The  DoD  Standard  Internet  Protocol  contains a number of
  2635.  
  2636. features which, while not strictly necessary in order for a  user
  2637.  
  2638. to  get his data delivered, and distinct from the type of service
  2639.  
  2640. field, do affect to some extent the service a user gets from  the
  2641.  
  2642.                              - 45 -
  2643.  
  2644.  
  2645. IEN 187                              Bolt Beranek and Newman Inc.
  2646.                                                     Eric C. Rosen
  2647.  
  2648.  
  2649. internet.   Some  of the features are worthy of comment, and that
  2650.  
  2651. is the purpose of this section.
  2652.  
  2653.  
  2654. 2.4.1  Time to Live
  2655.  
  2656.  
  2657.      The presence of the "time-to-live" field in the  Catenet  IP
  2658.  
  2659. seems  like  a clear example of something that has no place in an
  2660.  
  2661. access protocol.  The IP specification [1] has some contradictory
  2662.  
  2663. things to say about time-to-live.  The user is  supposed  to  set
  2664.  
  2665. this  field  to  the  number  of seconds after which he no longer
  2666.  
  2667. cares to have his information delivered, or something like  that.
  2668.  
  2669. It's  far from clear how some user is supposed to make a decision
  2670.  
  2671. as to what value to set this to.  For one  thing,  although  this
  2672.  
  2673. value is supposed to be represented in units of one second [1, p.
  2674.  
  2675. 24], there does not appear to be any requirement for the gateways
  2676.  
  2677. to  figure  out how many seconds to decrement this value by.  The
  2678.  
  2679. spec actually says that each gateway should decrement this  field
  2680.  
  2681. by  at  least  one,  even  if  it  has  no idea how much time has
  2682.  
  2683. actually elapsed [1, p. 40].  Well, a user  might  ask,  is  this
  2684.  
  2685. field  represented  in seconds or isn't it?  What is the point of
  2686.  
  2687. saying in  the  spec  that  it  is  in  seconds,  if  it  is  not
  2688.  
  2689. necessarily in seconds; this will only result in confusion.  That
  2690.  
  2691. is, any attempt by a user to set this field to a reasonable value
  2692.  
  2693. is  likely  to  have  unanticipated consequences.  Any attempt to
  2694.  
  2695. make inferences about internet  behavior  from  the  effect  that
  2696.  
  2697. various  settings  of  the time-to-live field will necessarily be
  2698.  
  2699. unreliable.
  2700.                              - 46 -
  2701.  
  2702.  
  2703. IEN 187                              Bolt Beranek and Newman Inc.
  2704.                                                     Eric C. Rosen
  2705.  
  2706.  
  2707.      At any rate, unless the Switches  all  keep  a  synchronized
  2708.  
  2709. clock,  there  is  no  real  way for them to determine how long a
  2710.  
  2711. packet has been in the network (or internet), as opposed  to  how
  2712.  
  2713. much  time  it has spent in the Switches, and this difference may
  2714.  
  2715. be significant  if  a  packet  is  sent  over  several  long-haul
  2716.  
  2717. networks  with  long-delay lines but fast Switches.  It's hard to
  2718.  
  2719. see the point of requiring a user  to  specify,  in  the  Network
  2720.  
  2721. Access  Protocol, a value which cannot be assigned any consistent
  2722.  
  2723. meaning.  (It's not clear what value this information has anyway;
  2724.  
  2725. according  to  the  IP  spec,  "the   intention   is   to   cause
  2726.  
  2727. undeliverable  datagrams  to  be  discarded"  [1,  p. 24].  But a
  2728.  
  2729. reasonable routing algorithm should cause undeliverable datagrams
  2730.  
  2731. to be discarded anyway, no matter what  value  is  specified  for
  2732.  
  2733. time-to-live).
  2734.  
  2735.  
  2736.      It  seems  plain  in  any  case  that  over  the years, Host
  2737.  
  2738. personnel will begin to tend to set this  field  to  its  maximum
  2739.  
  2740. value anyway.  In most implementations, the setting of this field
  2741.  
  2742. will  not  be left to the end-user, but will be in the code which
  2743.  
  2744. implements the IP.  Several years from now, no one will  remember
  2745.  
  2746. the  importance  of  setting  this  field correctly.  Eventually,
  2747.  
  2748. someone will discover that the data he sends to a  certain  place
  2749.  
  2750. does   not   get   through,   and   after   months  of  intensive
  2751.  
  2752. investigation, it will turn out that his IP is setting too  small
  2753.  
  2754. a value in the time-to-live field, and his packets are dying just
  2755.  
  2756. before  they reach their destination.  This will make people tend
  2757.  
  2758.                              - 47 -
  2759.  
  2760.  
  2761. IEN 187                              Bolt Beranek and Newman Inc.
  2762.                                                     Eric C. Rosen
  2763.  
  2764.  
  2765. to use the maximum value as a default, reducing  the  utility  of
  2766.  
  2767. the  information  to  almost nil.  (No one will want to spend the
  2768.  
  2769. time  re-tuning  this  value  to  the  optimum  as  the  internet
  2770.  
  2771. configuration  expands,  causing  real  packet  delays  to become
  2772.  
  2773. longer and longer.  In fact, at many Host sites there may not  be
  2774.  
  2775. anyone  who  can figure out enough of the Host code to be able to
  2776.  
  2777. re-tune this value.)
  2778.  
  2779.  
  2780.      Time-to-live, while useful for debugging purposes (perhaps),
  2781.  
  2782. has no real place in an operational  system,  and  hence  is  not
  2783.  
  2784. properly part of a Network Access Protocol.  If the Switches of a
  2785.  
  2786. Network  Structure  want to perform packet life timing functions,
  2787.  
  2788. in a  way  which  is  under  the  control  of  a  single  network
  2789.  
  2790. administration,   and   easily   modified   to  reflect  changing
  2791.  
  2792. realities, that is one thing.  It is quite a different  thing  to
  2793.  
  2794. build this into a Host-level protocol, with a contradictory spec,
  2795.  
  2796. where  it  will  certainly fall into disuse, or misuse.  Protocol
  2797.  
  2798. features  which  are  only   useful   (at   best)   for   network
  2799.  
  2800. experimenters  and  investigators are bound to cause trouble when
  2801.  
  2802. invoked at the Host level, as part of a protocol which every Host
  2803.  
  2804. must implement, and whose implementers may not  fully  understand
  2805.  
  2806. the implications of what they are doing.
  2807.  
  2808.  
  2809.      Some  of  these difficulties have, as their basic cause, the
  2810.  
  2811. old implicit model of the internet that we discussed in IEN  185.
  2812.  
  2813. The  IP  conflates  protocol features that properly belong to the
  2814.  
  2815.  
  2816.                              - 48 -
  2817.  
  2818.  
  2819. IEN 187                              Bolt Beranek and Newman Inc.
  2820.                                                     Eric C. Rosen
  2821.  
  2822.  
  2823. Network Access Protocol with features that properly belong to the
  2824.  
  2825. protocol used  internally  among  the  Switches.   This  sort  of
  2826.  
  2827. conflation,  and  consequent  violation of protocol layering, are
  2828.  
  2829. inevitable if the gateways are seen as hosts which patch networks
  2830.  
  2831. together, rather  than  as  Switches  in  an  autonomous  Network
  2832.  
  2833. Structure.
  2834.  
  2835.  
  2836. 2.4.2  Source Routing
  2837.  
  2838.  
  2839.      The  current  IP  has  a  feature known as "source routing,"
  2840.  
  2841. which allows each user to specify the sequence of  networks  that
  2842.  
  2843. his  internet  packet is to travel.  We mention this primarily as
  2844.  
  2845. an example of something that a Network Access Protocol in a truly
  2846.  
  2847. operational  environment  ought  not  to  have.   An   acceptable
  2848.  
  2849. internet  routing  algorithm  ought  to distribute the traffic in
  2850.  
  2851. order to achieve some general goal  on  an  internet-wide  basis,
  2852.  
  2853. such  as  minimizing delay, maximizing throughput, etc.  Any such
  2854.  
  2855. routing algorithm is subverted if each user is allowed to specify
  2856.  
  2857. his own route.   Much  of  the  routing  algorithm's  ability  to
  2858.  
  2859. prevent  or  avoid  congestion  is  also  compromised  if certain
  2860.  
  2861. packets are allowed to follow  a  route  pre-determined  by  some
  2862.  
  2863. user,  even if the routing algorithm determines that best service
  2864.  
  2865. (either for those packets themselves, or for other packets in the
  2866.  
  2867. internet) would be obtained if those packets followed a different
  2868.  
  2869. route.
  2870.  
  2871.  
  2872.  
  2873.  
  2874.                              - 49 -
  2875.  
  2876.  
  2877. IEN 187                              Bolt Beranek and Newman Inc.
  2878.                                                     Eric C. Rosen
  2879.  
  2880.  
  2881.      To a certain extent, the  presence  of  the  source  routing
  2882.  
  2883. option  in the IP is probably a result of the rather poor routing
  2884.  
  2885. strategy in the present Catenet,  and  a  way  of  attempting  to
  2886.  
  2887. obtain  better  service  than  the routing algorithm can actually
  2888.  
  2889. provide.  The long-term solution to  this  problem  would  be  to
  2890.  
  2891. improve  the  routing  algorithm,  rather than to subvert it with
  2892.  
  2893. something that is basically a kludge.  We would  claim  that  the
  2894.  
  2895. existence of any application or service that seems to require the
  2896.  
  2897. use  of  source  routing  is really an indication of some lack or
  2898.  
  2899. failure in the design of the internet,  and  a  proper  long-term
  2900.  
  2901. solution   is   to   improve   the   situation  by  making  basic
  2902.  
  2903. architectural changes in the internet, rather than by grafting on
  2904.  
  2905. new kludges.
  2906.  
  2907.  
  2908.      Source routing also has its use as an  experimental  device,
  2909.  
  2910. allowing tests to be performed which might indicate whether it is
  2911.  
  2912. really  worthwhile  to  add  some  new  feature or service to the
  2913.  
  2914. internet.  (Although the way in which source routing subverts the
  2915.  
  2916. basic internet routing algorithm can have disturbing side-effects
  2917.  
  2918. on the experimental results, which must  be  properly  controlled
  2919.  
  2920. for.)   However,  we  doubt  that  any  truly  useful experiments
  2921.  
  2922. requiring source routing can be performed by individual users  in
  2923.  
  2924. isolation.   Rather, useful experiments would seem to require the
  2925.  
  2926. cooperation and coordination of the participating users  as  well
  2927.  
  2928. as  those who are responsible for controlling and maintaining the
  2929.  
  2930. internet.  So it is not clear that there is any true  utility  to
  2931.  
  2932.                              - 50 -
  2933.  
  2934.  
  2935. IEN 187                              Bolt Beranek and Newman Inc.
  2936.                                                     Eric C. Rosen
  2937.  
  2938.  
  2939. having a source routing option at the level of the Network Access
  2940.  
  2941. Protocol,  thereby giving each and every user the option of using
  2942.  
  2943. it.  In an operational environment, this feature should either be
  2944.  
  2945. eliminated, or controlled  through  the  use  of  authorizations,
  2946.  
  2947. which would cause gateways to discard source-routed packets which
  2948.  
  2949. lack proper authorization.
  2950.  
  2951.  
  2952. 2.4.3  Fragmentation and Reassembly
  2953.  
  2954.  
  2955.      One  of  the  few  problems  which  is really specific to an
  2956.  
  2957. internet whose pathways consist of packet-switching  networks  is
  2958.  
  2959. the  fact  that  it is difficult to specify to the user a maximum
  2960.  
  2961. packet size to use when giving traffic to  the  internet.   If  a
  2962.  
  2963. user's  traffic is to go through EVERY component packet-switching
  2964.  
  2965. network, then the maximum packet size he can use is that  of  the
  2966.  
  2967. component  network with the smallest maximum packet size.  Yet it
  2968.  
  2969. seems unwise to require that no  user  ever  exceed  the  maximum
  2970.  
  2971. packet  size  of  the component network with the smallest maximum
  2972.  
  2973. packet size.  To do so might lead  to  very  inefficient  use  of
  2974.  
  2975. other  component networks which permit larger packet sizes.  If a
  2976.  
  2977. particular  user's  traffic  does  not  happen  to  traverse  the
  2978.  
  2979. component  network  with  the  smallest  maximum packet size, the
  2980.  
  2981. restriction really does no good, and only leads to  inefficiency.
  2982.  
  2983. Since,  in  a large internet, most traffic will probably traverse
  2984.  
  2985. only a small subset of the  component  networks,  this  is  quite
  2986.  
  2987. important.   In addition, some Hosts with limited resources might
  2988.  
  2989.  
  2990.                              - 51 -
  2991.  
  2992.  
  2993. IEN 187                              Bolt Beranek and Newman Inc.
  2994.                                                     Eric C. Rosen
  2995.  
  2996.  
  2997. have a high overhead on  a  per-packet  basis,  making  it  quite
  2998.  
  2999. important  to allow them to put larger packets into the internet.
  3000.  
  3001.  
  3002.      This gives rise to the question of, what should an  internet
  3003.  
  3004. Switch  do  if it must route a packet over a certain Pathway, but
  3005.  
  3006. that packet is larger than the maximum size of packets  that  can
  3007.  
  3008. be carried over that Pathway?  The solution that has been adopted
  3009.  
  3010. in  the  current  Catenet  is  to  allow the internet Switches to
  3011.  
  3012. "fragment" the packets  into  several  pieces  whenever  this  is
  3013.  
  3014. necessary in order to send the packet over a Pathway with a small
  3015.  
  3016. maximum packet size.  Each fragment of the original packet is now
  3017.  
  3018. treated  as  an  independent  datagram,  to  be  delivered to the
  3019.  
  3020. destination Host.  It is the responsibility  of  the  destination
  3021.  
  3022. Host  to  reassemble  the  original packet from all the fragments
  3023.  
  3024. before passing it up to the next highest protocol layer.  (If the
  3025.  
  3026. destination happens to have a high per-packet overhead, too bad.)
  3027.  
  3028.  
  3029.      The IP has several features whose only purpose is to  enable
  3030.  
  3031. this  reassembly.   These features are extremely general, so that
  3032.  
  3033. fragments can be further fragmented, ad  infinitum,  and  correct
  3034.  
  3035. reassembly  will  still be possible.  However, it seems that this
  3036.  
  3037. feature has not had very much operational testing in the Catenet;
  3038.  
  3039. gateway  implementers  seem  to  be  as  reluctant  to   actually
  3040.  
  3041. implement  fragmentation  as  Host  implementers are to implement
  3042.  
  3043. reassembly.  If at least one gateway does do fragmentation,  then
  3044.  
  3045. if  some Host does not do reassembly, it cannot, in general, talk
  3046.  
  3047.  
  3048.                              - 52 -
  3049.  
  3050.  
  3051. IEN 187                              Bolt Beranek and Newman Inc.
  3052.                                                     Eric C. Rosen
  3053.  
  3054.  
  3055. to any other Host on the internet.  If a source Host knows that a
  3056.  
  3057. destination Host does not do reassembly, then it can, through IP,
  3058.  
  3059. indicate to  the  gateways  that  they  ought  not  to  fragment.
  3060.  
  3061. However,  in  that  case, any datagrams that are not fragmentable
  3062.  
  3063. but which must be transmitted  over  a  Pathway  with  a  smaller
  3064.  
  3065. maximum packet size are simply lost in transit.
  3066.  
  3067.  
  3068.      It should be noted that the procedure of doing reassembly in
  3069.  
  3070. the  destination  Host violates the precepts of protocol layering
  3071.  
  3072. in a basic way.  The internet  is  not  transparent  to  protocol
  3073.  
  3074. modules in the Hosts, since a datagram put into the internet by a
  3075.  
  3076. protocol   module   in  the  source  Host  might  appear  at  the
  3077.  
  3078. destination Host in quite a different form, viz.,  as  a  set  of
  3079.  
  3080. fragments.   One  might  try to avoid this conclusion by claiming
  3081.  
  3082. that what we have been calling "the Host  software  modules"  are
  3083.  
  3084. really  part  of a Switch, rather than part of a Host, so that no
  3085.  
  3086. transparency is violated.  One could also claim that  a  dog  has
  3087.  
  3088. five legs, by agreeing to call its tail a leg.  But this would no
  3089.  
  3090. more  make a tail a leg than calling a Host software module "part
  3091.  
  3092. of the network" makes it so.   One  of  the  main  advantages  of
  3093.  
  3094. properly  layered  protocols is the ability it provides to change
  3095.  
  3096. the network without having to change the Hosts.  This  is  needed
  3097.  
  3098. if  changes  to  the  network  are even to be possible, since any
  3099.  
  3100. change  that  requires  Host  software  to  change  is,  for  all
  3101.  
  3102. practical  purposes, impossible.  This suggests that the boundary
  3103.  
  3104. of the network  be  drawn  at  the  boundary  where  changes  are
  3105.  
  3106.                              - 53 -
  3107.  
  3108.  
  3109. IEN 187                              Bolt Beranek and Newman Inc.
  3110.                                                     Eric C. Rosen
  3111.  
  3112.  
  3113. possible  without  coordination among an unlimited number of Host
  3114.  
  3115. administrations, and the natural place to draw this  boundary  is
  3116.  
  3117. around  the  Switches.  While the Switches of a Network Structure
  3118.  
  3119. can all be under the control  of  a  common  administration,  the
  3120.  
  3121. Hosts  cannot.   This  suggests  that  any  violation of protocol
  3122.  
  3123. layering that is as gross as the need to have Hosts do reassembly
  3124.  
  3125. is a problem that is to be avoided whenever possible.
  3126.  
  3127.  
  3128.      The problems of writing Host-level software to do reassembly
  3129.  
  3130. in a reliable manner do not seem to have been fully  appreciated.
  3131.  
  3132. If a Host's resources (such as buffer space, queuing slots, table
  3133.  
  3134. areas,  etc.)  are very highly utilized, all sorts of performance
  3135.  
  3136. sub-optimalities   are   possible.    Without   adequate   buffer
  3137.  
  3138. management  (see  IEN 182), even lock-ups are possible.  One must
  3139.  
  3140. remember that reassembly is not a simple matter  of  sending  the
  3141.  
  3142. fragments  to  the  next higher level process in proper sequence.
  3143.  
  3144. The situation is more complex, since  the  first  fragment  of  a
  3145.  
  3146. datagram  cannot  be  sent  up  to the next higher protocol level
  3147.  
  3148. until all the  fragments  of  that  datagram  are  received.   If
  3149.  
  3150. buffers  are  not  pre-allocated  at  the  destination Host, then
  3151.  
  3152. fragments of some datagrams may need to be  discarded  to  ensure
  3153.  
  3154. that  there  is  room  to  hold  all  the fragments of some other
  3155.  
  3156. datagram; otherwise "reassembly  lockup"  is  possible.   If  the
  3157.  
  3158. internet  gateways really did a large amount of fragmentation, so
  3159.  
  3160. that Hosts needed to do a large amount of reassembly, this  would
  3161.  
  3162. almost  certainly  give rise to a variety of peculiar performance
  3163.  
  3164.                              - 54 -
  3165.  
  3166.  
  3167. IEN 187                              Bolt Beranek and Newman Inc.
  3168.                                                     Eric C. Rosen
  3169.  
  3170.  
  3171. problems and  phasing  effects  which  could  make  the  recently
  3172.  
  3173. discovered   "silly   window   syndrome"   look   quite   benign.
  3174.  
  3175. Unfortunately, it is hard to gain an appreciation of these  sorts
  3176.  
  3177. of  problems  until one has personally encountered them, at which
  3178.  
  3179. point it is often too late to do anything about them.
  3180.  
  3181.  
  3182.      Performance   considerations   (as   opposed    simply    to
  3183.  
  3184. considerations  of  functionality)  would  seem  to indicate that
  3185.  
  3186. fragmentation and reassembly be avoided whenever possible.   Note
  3187.  
  3188. that  performance  problems associated with reassembly might crop
  3189.  
  3190. up suddenly at any time in the life of the internet, as some Host
  3191.  
  3192. which rarely received fragments in the past suddenly finds itself
  3193.  
  3194. bombarded with them, possibly due to a  new  application.   Since
  3195.  
  3196. this  sort  of  effect  is  notoriously  difficult to test out in
  3197.  
  3198. advance, one would expect potential problems to be lying in wait.
  3199.  
  3200. Problems like these tend to crop up  at  a  time  when  the  Host
  3201.  
  3202. administration  has  no  one  available  who  understands and can
  3203.  
  3204. modify the Host software, which means that such problems  can  be
  3205.  
  3206. very  intransigent  and difficult to remedy.  Of course, problems
  3207.  
  3208. in Host networking software are usually  blamed  on  the  network
  3209.  
  3210. (i.e.,  on  the  Switches),  which  also  does  not help to speed
  3211.  
  3212. problem resolution.
  3213.  
  3214.  
  3215.      One way to remove this sort of problem from the Host  domain
  3216.  
  3217. is  to  have the destination Switches themselves do any necessary
  3218.  
  3219. reassembly before passing a datagram on to its destination  Host.
  3220.  
  3221.  
  3222.                              - 55 -
  3223.  
  3224.  
  3225. IEN 187                              Bolt Beranek and Newman Inc.
  3226.                                                     Eric C. Rosen
  3227.  
  3228.  
  3229. This  has the advantage that problems which arise will fall under
  3230.  
  3231. the domain of the Network administration, which is more likely to
  3232.  
  3233. be  able  to  deal  with  them  than   are   the   various   Host
  3234.  
  3235. administrations.   However,  this  really  does  not simplify the
  3236.  
  3237. situation, or reduce the amount of  performance  sub-optimalities
  3238.  
  3239. that  we might be faced with; it just takes the same problems and
  3240.  
  3241. puts them somewhere else.  ARPANET IMPs do fragmentation  (though
  3242.  
  3243. only  at  the  source IMP) and reassembly at the destination IMP,
  3244.  
  3245. and this has turned out to be quite a tricky  and  problem-strewn
  3246.  
  3247. mechanism.  Other approaches should be investigated.
  3248.  
  3249.  
  3250.      Of course, one possible way around fragmentation is to adopt
  3251.  
  3252. a  policy  of  not routing any packets over Pathways which cannot
  3253.  
  3254. handle packets of that  size.   If  there  are  several  possible
  3255.  
  3256. routes   between  source  and  destination,  which  have  similar
  3257.  
  3258. characteristics except for the  fact  that  one  of  them  has  a
  3259.  
  3260. maximum  packet size which is too small, the most efficient means
  3261.  
  3262. of handling this problem might just be to avoid using  the  route
  3263.  
  3264. which  would  require fragmentation.  Even if this means taking a
  3265.  
  3266. slightly longer route to the destination, the extra delay imposed
  3267.  
  3268. during internet transit might be more than compensated for by the
  3269.  
  3270. reduction in delay that would be  obtained  by  not  forcing  the
  3271.  
  3272. destination  Host  to  do  reassembly.   Of  course,  this scheme
  3273.  
  3274. requires interaction with routing, but as long  as  there  are  a
  3275.  
  3276. small number of possible maximum packet sizes, this scheme is not
  3277.  
  3278. difficult  to  implement  (at  least,  given a reasonable routing
  3279.  
  3280. algorithm).
  3281.                              - 56 -
  3282.  
  3283.  
  3284. IEN 187                              Bolt Beranek and Newman Inc.
  3285.                                                     Eric C. Rosen
  3286.  
  3287.  
  3288.      Unfortunately, it might be the case that there  just  is  no
  3289.  
  3290. route  at  all to a particular destination, or else no reasonable
  3291.  
  3292. route, which does not utilize a Pathway whose maximum packet size
  3293.  
  3294. is "too  small."   In  this  case,  there  seems  no  way  around
  3295.  
  3296. fragmentation  and  reassembly.  However, a scheme which is worth
  3297.  
  3298. considering  is  that  of  doing  hop-by-hop  fragmentation   and
  3299.  
  3300. reassembly  within  the  internet.   That  is, rather than having
  3301.  
  3302. reassembly done at  the  destination  (Switch  or  Host),  it  is
  3303.  
  3304. possible  to  do reassembly at the Switch which is the exit point
  3305.  
  3306. from a component network which  has  an  unusually  small  packet
  3307.  
  3308. size.  Datagrams would be fragmented upon entry to such networks,
  3309.  
  3310. and reassembled upon exit from them, with no burden on either the
  3311.  
  3312. destination  Switch  or  the  destination  Host.   The  fact that
  3313.  
  3314. fragments would never travel more than one hop without reassembly
  3315.  
  3316. ameliorates the performance problems somewhat, since  the  amount
  3317.  
  3318. of  time  a  partially reassembled datagram might have to be held
  3319.  
  3320. would be less, in general, than if reassembly  were  done  on  an
  3321.  
  3322. end-end basis.
  3323.  
  3324.  
  3325.      A  strategy of doing hop-by-hop reassembly and fragmentation
  3326.  
  3327. also allows more efficient use  of  the  internet's  Pathways  in
  3328.  
  3329. certain  cases.   One  problem  with  the end-end strategy is the
  3330.  
  3331. essential "randomness" of its effects.  Consider, for example,  a
  3332.  
  3333. large  packet  which  must  traverse  several networks with large
  3334.  
  3335. maximum packet sizes, and then one network with a  small  maximum
  3336.  
  3337. packet  size.   The  current  method  of  doing fragmentation and
  3338.  
  3339.                              - 57 -
  3340.  
  3341.  
  3342. IEN 187                              Bolt Beranek and Newman Inc.
  3343.                                                     Eric C. Rosen
  3344.  
  3345.  
  3346. reassembly allows the  packet  to  remain  large  throughout  the
  3347.  
  3348. networks  that can handle it, fragmenting it only when it reaches
  3349.  
  3350. its final hop.  This seems efficient  enough,  but  consider  the
  3351.  
  3352. case  where  the  FIRST  internet  hop  is  the  network with the
  3353.  
  3354. smallest maximum packet size, and the remaining hops are networks
  3355.  
  3356. with large maximum  packet  sizes.   The  current  strategy  then
  3357.  
  3358. causes  a  very inefficient use of the internet, since the packet
  3359.  
  3360. must now travel fragmented through ALL  the  networks,  including
  3361.  
  3362. the  ones  which  would allow the larger packet size.  If some of
  3363.  
  3364. these networks impose constraints on a  per-packet  basis  (which
  3365.  
  3366. might either be flow control constraints, or monetary constraints
  3367.  
  3368. based  on  per-packet  billing),  this  inefficiency  can  have a
  3369.  
  3370. considerable cost.  Hop-by-hop reassembly,  on  the  other  hand,
  3371.  
  3372. would  allow  the  large  packet  to be reassembled and to travel
  3373.  
  3374. through the remaining networks in the most cost-effective manner.
  3375.  
  3376. Such a strategy is most consonant with our general thesis that an
  3377.  
  3378. efficient and reliable internet must contain Switches  which  are
  3379.  
  3380. specifically  tuned  to  the  characteristics  of  the individual
  3381.  
  3382. Pathways.  It also removes the  problem  from  the  Host  domain,
  3383.  
  3384. making  the  system  more consonant with the precepts of protocol
  3385.  
  3386. layering.
  3387.  
  3388.  
  3389.      There is, unfortunately, one situation in  which  hop-by-hop
  3390.  
  3391. fragmentation   cannot   work.    If  the  Pathway  between  some
  3392.  
  3393. destination Host and the destination Switch has a  small  maximum
  3394.  
  3395. packet  size,  so  that  the  destination  Switch  must  fragment
  3396.  
  3397.                              - 58 -
  3398.  
  3399.  
  3400. IEN 187                              Bolt Beranek and Newman Inc.
  3401.                                                     Eric C. Rosen
  3402.  
  3403.  
  3404. datagrams intended for that Host, then reassembly must be done by
  3405.  
  3406. the Host itself, since there is no Switch at the other end of the
  3407.  
  3408. Pathway to do the reassembly.  This  seems  to  mean  that  Hosts
  3409.  
  3410. whose  "home  networks" have unusually small maximum packet sizes
  3411.  
  3412. will be forced to implement the ability  to  perform  reassembly,
  3413.  
  3414. and must tolerate any resultant performance disadvantages.
  3415.  
  3416.  
  3417.  
  3418. 2.5  Flow Control
  3419.  
  3420.  
  3421.      The  topic  of  "flow  control"  or "congestion control" (we
  3422.  
  3423. shall be employing these terms rather  interchangeably,  ignoring
  3424.  
  3425. any  pedantic  distinctions  between  them) breaks down naturally
  3426.  
  3427. into a number  of  sub-topics.   In  this  section  we  shall  be
  3428.  
  3429. concerned  with  only  one such sub-topic, namely, how should the
  3430.  
  3431. Switches  of  the  Network   Structure   enforce   flow   control
  3432.  
  3433. restrictions  on the Hosts?  We shall not consider here the issue
  3434.  
  3435. of how the Switches should do  internal  flow  control,  or  what
  3436.  
  3437. protocols  they  need to run among themselves to disseminate flow
  3438.  
  3439. control information, but only the issue of how the results of any
  3440.  
  3441. internal flow control algorithm should be fed back to the  hosts.
  3442.  
  3443. The  IP  is  a rather unusual Network Access Protocol, in that it
  3444.  
  3445. does not have any flow or congestion  control  features  at  all.
  3446.  
  3447. This  makes  it  very  different  from  most other Network Access
  3448.  
  3449. Protocols, such as 1822 or X.25, which do have ways  of  imposing
  3450.  
  3451. controls  on  the  rate  at  which  users  can  put data into the
  3452.  
  3453. network.  The IP,  on  the  other  hand,  is  supposed  to  be  a
  3454.  
  3455.                              - 59 -
  3456.  
  3457.  
  3458. IEN 187                              Bolt Beranek and Newman Inc.
  3459.                                                     Eric C. Rosen
  3460.  
  3461.  
  3462. "datagram  protocol", and therefore (?) is not supposed to impose
  3463.  
  3464. any flow or congestion control restrictions on the rate at  which
  3465.  
  3466. data  can  be  sent  into the internet.  In this section, we will
  3467.  
  3468. discuss whether this is appropriate, and whether the  "therefore"
  3469.  
  3470. of the previous sentence is really correctly used.
  3471.  
  3472.  
  3473.  
  3474.      The  issue  of  how  flow or congestion control restrictions
  3475.  
  3476. ought to be passed back to a  Host,  or  more  generally,  how  a
  3477.  
  3478. Network   Structure  ought  to  enforce  its  congestion  control
  3479.  
  3480. restrictions, is a tricky  issue.   Particularly  tricky  is  the
  3481.  
  3482. relation  between datagram protocols and flow control.  Datagrams
  3483.  
  3484. are sometimes known (especially with reference to the ARPANET) as
  3485.  
  3486. "uncontrolled packets," which  tends  to  suggest  that  no  flow
  3487.  
  3488. control should be applied to them.  This way of thinking may be a
  3489.  
  3490. holdover  from  the  early days of the ARPANET, when it was quite
  3491.  
  3492. lightly loaded.  In  those  days,  the  flow  control  which  the
  3493.  
  3494. ARPANET  imposes  was  much too strict, holding the throughput of
  3495.  
  3496. particular connections to  an  unreasonably  low  value.   Higher
  3497.  
  3498. throughput  could often be obtained by ignoring the controls, and
  3499.  
  3500. just sending as  much  traffic  as  necessary  for  a  particular
  3501.  
  3502. application.   Since the network was lightly loaded, ignoring the
  3503.  
  3504. controls did not cause much congestion.  Of course, this strategy
  3505.  
  3506. breaks down when applied to the more heavily  loaded  ARPANET  of
  3507.  
  3508. today.    Too   much   uncontrolled   traffic  can  cause  severe
  3509.  
  3510. congestion, which reduces throughput  for  everybody.   Therefore
  3511.  
  3512.  
  3513.                              - 60 -
  3514.  
  3515.  
  3516. IEN 187                              Bolt Beranek and Newman Inc.
  3517.                                                     Eric C. Rosen
  3518.  
  3519.  
  3520. many  people  now  tend  to  recognize  the  need  to control the
  3521.  
  3522. uncontrolled  packets,  if  we  may  be  forgiven  that  apparent
  3523.  
  3524. contradiction.   Clearly,  there  is  some tension here, since it
  3525.  
  3526. makes  little  sense  to  regard  the  same   traffic   as   both
  3527.  
  3528. "controlled" and "uncontrolled."  If a Network Access Protocol is
  3529.  
  3530. developed  on  the  assumption  that  it  should  be  a "datagram
  3531.  
  3532. protocol", and hence need not apply any controls to the  rate  at
  3533.  
  3534. which data can be transferred, it will not be an effective medium
  3535.  
  3536. for   the   enforcement  of  flow  control  restrictions  at  the
  3537.  
  3538. host-network access point.  If  congestion  begins  to  become  a
  3539.  
  3540. problem, so that people gradually begin to realize the importance
  3541.  
  3542. of  congestion  control,  they  will find that the Network Access
  3543.  
  3544. Protocol gives them no way to force the Hosts to  restrict  their
  3545.  
  3546. traffic  when  that  is  necessary.   The probable result of this
  3547.  
  3548. scenario would  be  to  try  to  develop  a  scheme  to  get  the
  3549.  
  3550. congestion  control  information  to  the  Hosts  in  a  way that
  3551.  
  3552. bypasses the Network  Access  Protocol.   This  is  our  "logical
  3553.  
  3554. reconstruction"  of  the  current situation in the Catenet.  When
  3555.  
  3556. gateways think  that  there  is  congestion,  they  send  "source
  3557.  
  3558. quench"  packets  to  the  Hosts  themselves,  and  the Hosts are
  3559.  
  3560. supposed to do something to reduce the congestion.   This  source
  3561.  
  3562. quench  mechanism  should  be recognized for what it is, namely a
  3563.  
  3564. protocol which  is  run  between  EVERY  host  and  EVERY  Switch
  3565.  
  3566. (including  intermediate  Switches,  not  just  source  Switches)
  3567.  
  3568. within a Network Structure, and  which  completely  bypasses  the
  3569.  
  3570.  
  3571.                              - 61 -
  3572.  
  3573.  
  3574. IEN 187                              Bolt Beranek and Newman Inc.
  3575.                                                     Eric C. Rosen
  3576.  
  3577.  
  3578. Network Access Protocol (IP).  This violates protocol layering in
  3579.  
  3580. a  very  basic  way,  since proper layering seems to imply that a
  3581.  
  3582. source Host should have to run a protocol with  a  source  Switch
  3583.  
  3584. only, not with every Switch in the network.
  3585.  
  3586.  
  3587.      Of  course,  the fact that some mechanism appears to violate
  3588.  
  3589. the constraints of protocol layering is not necessarily  a  fatal
  3590.  
  3591. objection  to it.  However, given the present state of the art of
  3592.  
  3593. flow control techniques, which is quite primitive,  flow  control
  3594.  
  3595. procedures  must  be  designed  in  a way that permits them to be
  3596.  
  3597. easily modified, or even completely changed,  as  we  learn  more
  3598.  
  3599. about  flow control.  We must be able to make any sort of changes
  3600.  
  3601. to the internal flow control mechanism  of  a  Network  Structure
  3602.  
  3603. without  any  need  to make changes in Host-level software at the
  3604.  
  3605. same time.   ARPANET  experience  indicates  quite  clearly  that
  3606.  
  3607. changes  which  would  be technically salutary, but which require
  3608.  
  3609. Host software modifications, are virtually  impossible  to  make.
  3610.  
  3611. Host  personnel cannot justify large expenditures of their own to
  3612.  
  3613. make changes for which they perceive no  crucial  need  of  their
  3614.  
  3615. own,  just  because  network  personnel believe the changes would
  3616.  
  3617. result in better network service.  If  we  want  to  be  able  to
  3618.  
  3619. experiment with different internal flow control techniques in the
  3620.  
  3621. internet,  then  we  must  provide  a clean interface between the
  3622.  
  3623. internal flow control  protocols,  and  the  way  in  which  flow
  3624.  
  3625. control  information  is fed back to the Hosts.  We must define a
  3626.  
  3627. relatively simple and straightforward interface by which a source
  3628.  
  3629.                              - 62 -
  3630.  
  3631.  
  3632. IEN 187                              Bolt Beranek and Newman Inc.
  3633.                                                     Eric C. Rosen
  3634.  
  3635.  
  3636. Switch  can  enforce  flow  control  restrictions  on   a   Host,
  3637.  
  3638. independently  of  how  the  source  Switch  determines just what
  3639.  
  3640. restrictions to enforce.  The way in which the Switches determine
  3641.  
  3642. these restrictions can be changed as we  learn  more  about  flow
  3643.  
  3644. control, but the Host interface will remain the same.
  3645.  
  3646.  
  3647.      It  is  not  clear that the source quench mechanism has been
  3648.  
  3649. generally recognized as a new sort of  protocol,  which  bypasses
  3650.  
  3651. the  usual  Network  Access  Protocol for the internet (IP).  One
  3652.  
  3653. reason that it may seem strange to dignify  this  mechanism  with
  3654.  
  3655. the  name of "protocol" is that no one really knows what a source
  3656.  
  3657. quench packet really means, and no one really knows what they are
  3658.  
  3659. supposed to do when they get one.  So generally,  they  are  just
  3660.  
  3661. ignored,  and  the "procedure" of ignoring a control packet seems
  3662.  
  3663. like a very degenerate case of a protocol.  Further,  the  source
  3664.  
  3665. quench  mechanism  is a protocol which Host software implementers
  3666.  
  3667. seem to feel free to violate with impunity.  No implementer could
  3668.  
  3669. decide to ignore the protocols governing the form of addresses in
  3670.  
  3671. the internet, or he would never be able to send or receive  data.
  3672.  
  3673. Yet  there  is  no  penalty  for  ignoring source quench packets,
  3674.  
  3675. although violating the flow  control  part  of  the  internetting
  3676.  
  3677. protocol seems like something that really ought to be prohibited.
  3678.  
  3679. (We have even heard rumors of Host software implementers who have
  3680.  
  3681. decided  to increase their rate of traffic flow into the internet
  3682.  
  3683. upon receiving a source quench packet, on  the  grounds  that  if
  3684.  
  3685. they  are  receiving source quench packets, some of their traffic
  3686.  
  3687.                              - 63 -
  3688.  
  3689.  
  3690. IEN 187                              Bolt Beranek and Newman Inc.
  3691.                                                     Eric C. Rosen
  3692.  
  3693.  
  3694. is not getting through, and therefore they had better  retransmit
  3695.  
  3696. their traffic right away.)
  3697.  
  3698.  
  3699.      We  have  spoken  of  a  source Switch needing to be able to
  3700.  
  3701. ENFORCE flow control restrictions, by which we mean that  when  a
  3702.  
  3703. source  Switch  determines  that  a  certain source Host ought to
  3704.  
  3705. reduce its rate of traffic, the  Switch  will  REFUSE  to  accept
  3706.  
  3707. traffic  at  a  faster  rate.   Proper  flow control can never be
  3708.  
  3709. accomplished if we have to rely either on the good  will  or  the
  3710.  
  3711. good  sense  of  Host software implementers.  (Remember that Host
  3712.  
  3713. software  implementations  will  continue  for  years  after  the
  3714.  
  3715. internet  becomes operational, and future implementers may not be
  3716.  
  3717. as conversant as current implementers  with  networking  issues).
  3718.  
  3719. This  means  a  major  change to the IP concept.  Yet it seems to
  3720.  
  3721. make much more  sense  to  enhance  the  Catenet  Network  Access
  3722.  
  3723. Protocol  to  allow  for  flow  control than to try to bypass the
  3724.  
  3725. Network Access Protocol entirely by sending  control  information
  3726.  
  3727. directly from intermediate Switches to a Host which is only going
  3728.  
  3729. to ignore it.
  3730.  
  3731.  
  3732.      We  will  not discuss internal flow control mechanisms here,
  3733.  
  3734. except to say that we do not believe at  all  in  "choke  packet"
  3735.  
  3736. schemes,  of  which  the  source  quench mechanism is an example.
  3737.  
  3738. Eventually, we will propose an internal congestion control scheme
  3739.  
  3740. for the internet, but it will not look at  all  like  the  source
  3741.  
  3742. quench  mechanism.   (Chapters  5  and  6  of  [2]  contain  some
  3743.  
  3744.  
  3745.                              - 64 -
  3746.  
  3747.  
  3748. IEN 187                              Bolt Beranek and Newman Inc.
  3749.                                                     Eric C. Rosen
  3750.  
  3751.  
  3752. interesting discussions of congestion control in general, and  of
  3753.  
  3754. choke  packet  schemes  in  particular.)   It  appears  that some
  3755.  
  3756. internet workers are now becoming concerned  with  the  issue  of
  3757.  
  3758. what  to do when source quench packets are received, but this way
  3759.  
  3760. of putting the question is somewhat misdirected.   When  you  get
  3761.  
  3762. some  information, and you still don't know what decision to make
  3763.  
  3764. or what action to take, maybe the problem is not so much  in  the
  3765.  
  3766. decision-making  process as it is in the information.  The proper
  3767.  
  3768. question is not, "what should we do when  we  get  source  quench
  3769.  
  3770. packets?",  but  rather  "what  should  we  get instead of source
  3771.  
  3772. quench  packets  that  would  provide  a  clear  and   meaningful
  3773.  
  3774. indication as to what we should do?
  3775.  
  3776.  
  3777.      Does  this  mean  that  the internet Network Access Protocol
  3778.  
  3779. should not really be a datagram protocol?  To some  extent,  this
  3780.  
  3781. is  merely  a  terminological  issue.   There  is no reason why a
  3782.  
  3783. protocol cannot enforce congestion or flow control  without  also
  3784.  
  3785. imposing reliability or sequentiality, or any other features that
  3786.  
  3787. may unnecessarily add delay or reduce throughput.  Whether such a
  3788.  
  3789. protocol  would be called a "datagram protocol" is a matter of no
  3790.  
  3791. import.  It is worth noting,  though,  that  the  Network  Access
  3792.  
  3793. Protocol  of  AUTODIN  II  (SIP),  while  officially  known  as a
  3794.  
  3795. datagram  protocol,  does  impose  and   enforce   flow   control
  3796.  
  3797. restrictions on its hosts.
  3798.  
  3799.  
  3800.  
  3801.  
  3802.  
  3803.                              - 65 -
  3804.  
  3805.  
  3806. IEN 187                              Bolt Beranek and Newman Inc.
  3807.                                                     Eric C. Rosen
  3808.  
  3809.  
  3810.      The  only  real  way for a source Switch to enforce its flow
  3811.  
  3812. control restrictions on a source Host is simply for the Switch to
  3813.  
  3814. REFUSE packets from that Host if the Host is sending too rapidly.
  3815.  
  3816. At its simplest, the Switch could simply drop the  packets,  with
  3817.  
  3818. no  further action.  A somewhat more complex procedure would have
  3819.  
  3820. the Switch inform the Host that a packet had been dropped.  A yet
  3821.  
  3822. more complex procedure would tell the Host  when  to  try  again.
  3823.  
  3824. Even more complex schemes, like the windowing scheme of X.25, are
  3825.  
  3826. also possible.  To make any of these work, however, it seems that
  3827.  
  3828. a  source  Switch  (gateway)  will have to maintain Host-specific
  3829.  
  3830. traffic information, which will inevitably place a limit  on  the
  3831.  
  3832. number   of   Hosts   that  can  be  accessing  a  source  Switch
  3833.  
  3834. simultaneously.  Yet this seems inevitable  if  we  are  to  take
  3835.  
  3836. seriously  the  need for flow control.  At any rate, the need for
  3837.  
  3838. flow control really implies the need for the  existence  of  such
  3839.  
  3840. limits.
  3841.  
  3842.  
  3843.  
  3844. 2.6  Pathway Access Protocol Instrumentation
  3845.  
  3846.  
  3847.      Fault  isolation  in  an  internet  environment  is  a  very
  3848.  
  3849. difficult task, since there are so many components, and  so  many
  3850.  
  3851. ways  for  each  to fail, that a performance problem perceived by
  3852.  
  3853. the user may be caused by any of a thousand different  scenarios.
  3854.  
  3855. Furthermore,  by the time the problem becomes evident at the user
  3856.  
  3857. level, information as to the cause of the  problem  may  be  long
  3858.  
  3859. gone.  Effective fault isolation in the internet environment will
  3860.  
  3861.                              - 66 -
  3862.  
  3863.  
  3864. IEN 187                              Bolt Beranek and Newman Inc.
  3865.                                                     Eric C. Rosen
  3866.  
  3867.  
  3868. require   proper  instrumentation  in  ALL  internet  components,
  3869.  
  3870. including the Hosts.  We will end this paper with a  few  remarks
  3871.  
  3872. about the sort of instrumentation that Hosts should have, to help
  3873.  
  3874. in fault-isolation when there is an apparent network problem.  We
  3875.  
  3876. have  very  often found people blaming the ARPANET for lost data,
  3877.  
  3878. when in fact the problem is entirely within the host itself.  The
  3879.  
  3880. main source of this difficulty is that there often is no way  for
  3881.  
  3882. host  personnel  to  find  out  what is happening within the host
  3883.  
  3884. software.  Sometimes host personnel will attempt  to  deduce  the
  3885.  
  3886. source  of the apparent problem by watching the lights on the IMP
  3887.  
  3888. interface blink, and putting that information together  with  the
  3889.  
  3890. folklore  that  they have heard about the network (which folklore
  3891.  
  3892. is rarely true).  Our ARPANET experience shows quite clearly that
  3893.  
  3894. this sort of fault-isolation procedure just is not useful at all.
  3895.  
  3896. What is really needed is a  much  more  complex,  objective,  and
  3897.  
  3898. SYSTEMATIC  form  of instrumentation, which unfortunately is much
  3899.  
  3900. more difficult to do than simply looking at the blinking  lights.
  3901.  
  3902.  
  3903.      Some  sorts  of essential instrumentation are quite specific
  3904.  
  3905. to the sort of Network Access Protocol or Pathway Access Protocol
  3906.  
  3907. that is being used.  For example,  users  of  the  ARPANET  often
  3908.  
  3909. complain  that  the  IMP  is blocking their host for an excessive
  3910.  
  3911. amount of time.  By itself, this information is not very  useful,
  3912.  
  3913. since  it  is only a symptom which can have any of a large number
  3914.  
  3915. of causes.  In particular, the host itself may be forcing the IMP
  3916.  
  3917. to  block  by  attempting  to  violate   ARPANET   flow   control
  3918.  
  3919.                              - 67 -
  3920.  
  3921.  
  3922. IEN 187                              Bolt Beranek and Newman Inc.
  3923.                                                     Eric C. Rosen
  3924.  
  3925.  
  3926. restrictions.   One sort of instrumentation which would be useful
  3927.  
  3928. for the host to have is a way of keeping track of the total  time
  3929.  
  3930. it is blocked by the IMP, with the blocking time divided into the
  3931.  
  3932. following categories:
  3933.  
  3934.  
  3935.      1) Time blocked between messages.
  3936.  
  3937.  
  3938.      2) Time blocked between the leader of a message and the data
  3939.  
  3940.         of the message.
  3941.  
  3942.  
  3943.      3) Time blocked between packets.
  3944.  
  3945.  
  3946.      4) Time blocked while  attempting  to  send  a  multi-packet
  3947.  
  3948.         message (a subset of 2).
  3949.  
  3950.  
  3951.      5) Time blocked during transmission of the data portion of a
  3952.  
  3953.         packet.
  3954.  
  3955.  
  3956.      6) Time blocked while attempting to transmit a  datagram  (a
  3957.  
  3958.         subset of 2).
  3959.  
  3960.  
  3961.      While  this information might be very non-trivial for a host
  3962.  
  3963. to gather, it does not help us very much in  fixing  the  problem
  3964.  
  3965. just  to  know  that  "the  IMP  is blocking" unless we can get a
  3966.  
  3967. breakdown like this.  In addition, it is  useful  to  have  those
  3968.  
  3969. categories  further  broken down by destination Host, in case the
  3970.  
  3971. blocking is specific to some particular set of hosts.
  3972.  
  3973.  
  3974.  
  3975.  
  3976.  
  3977.                              - 68 -
  3978.  
  3979.  
  3980. IEN 187                              Bolt Beranek and Newman Inc.
  3981.                                                     Eric C. Rosen
  3982.  
  3983.  
  3984.      Additional useful information has to do with the 1822  reply
  3985.  
  3986. messages.  What percentage of transmitted messages are replied to
  3987.  
  3988. with  RFNMs?  with  DEADs? with INCOMPLETEs?  This should also be
  3989.  
  3990. broken down by destination host.  In fact, it would be useful  to
  3991.  
  3992. keep  track  of the number of each possible 1822 IMP-host control
  3993.  
  3994. message that  is  received.   When  problems  arise,  it  may  be
  3995.  
  3996. possible to correlate this information with the problem symptoms.
  3997.  
  3998.  
  3999.      The  basic idea here should be clear -- besides just telling
  4000.  
  4001. us that "the network isn't  taking  packets  fast  enough",  host
  4002.  
  4003. personnel  should  be  able  to tell us under what conditions the
  4004.  
  4005. network is or is not taking packets, and just what "fast  enough"
  4006.  
  4007. means.   If  a host is also running an access protocol other than
  4008.  
  4009. (or in addition to) 1822, there  will  be  specific  measurements
  4010.  
  4011. relevant  to  the operation of that protocol, but in order to say
  4012.  
  4013. just what they are, one must be familiar  with  those  particular
  4014.  
  4015. protocols.   (Again  we  see  the  effects  of particular Pathway
  4016.  
  4017. characteristics, this time on the sort of instrumentation  needed
  4018.  
  4019. for  good  fault  isolation.)   In general, whenever any protocol
  4020.  
  4021. module is designed and implemented, the designer AND  implementer
  4022.  
  4023. (each  of  whom  can  contribute  from  a  different  but equally
  4024.  
  4025. valuable  perspective)  should  try  to  think  of  anything  the
  4026.  
  4027. protocol  or  the  software  module  which implements it might do
  4028.  
  4029. which could hold up traffic  flow  (e.g.,  flow  control  windows
  4030.  
  4031. being  closed,  running  out of sequence number space, failing to
  4032.  
  4033. get timely acknowledgments, process getting swapped  out,  etc.),
  4034.  
  4035.                              - 69 -
  4036.  
  4037.  
  4038. IEN 187                              Bolt Beranek and Newman Inc.
  4039.                                                     Eric C. Rosen
  4040.  
  4041.  
  4042. and should be able to gather statistics (say, average and maximum
  4043.  
  4044. values  of  the amount of time data transfer is being held up for
  4045.  
  4046. each possible cause) which tell us how  the  protocol  module  is
  4047.  
  4048. performing.
  4049.  
  4050.  
  4051.      If  a protocol requires (or allows) retransmissions, rate of
  4052.  
  4053. retransmission is a very useful statistic, especially  if  broken
  4054.  
  4055. down by destination host.
  4056.  
  4057.  
  4058.      Hosts should be able to supply statistics on the utilization
  4059.  
  4060. of  host  resources.   Currently,  for example, many hosts cannot
  4061.  
  4062. even provide any information about their buffer  utilization,  or
  4063.  
  4064. about  the  lengths  of  the  various  queues which a packet must
  4065.  
  4066. traverse when traveling (in either direction)  between  the  host
  4067.  
  4068. and  the  IMP.   Yet  very  high  buffer utilization or very long
  4069.  
  4070. queues within the host may be a source of  performance  problems.
  4071.  
  4072. When a packet has to go through several protocol modules within a
  4073.  
  4074. host  (say, from TELNET to TCP to IP to 1822), the host should be
  4075.  
  4076. able to supply statistics on average and maximum times  it  takes
  4077.  
  4078. for a packet to get through each of these modules.  This can help
  4079.  
  4080. in  the  discovery  of  unexpected  or  unanticipated bottlenecks
  4081.  
  4082. within the host.  (For example, packets may take an  unexpectedly
  4083.  
  4084. long  amount  of time to get through a certain module because the
  4085.  
  4086. module  is  often  swapped  out.   This  is  something  that   is
  4087.  
  4088. especially likely to happen some years after the host software is
  4089.  
  4090. initially  developed, when no one remembers anymore that the host
  4091.  
  4092.  
  4093.                              - 70 -
  4094.  
  4095.  
  4096. IEN 187                              Bolt Beranek and Newman Inc.
  4097.                                                     Eric C. Rosen
  4098.  
  4099.  
  4100. networking software is supposed to have a  high  priority.   This
  4101.  
  4102. sort  of  instrumentation  can be quite tricky to get just right,
  4103.  
  4104. since one must make sure that there is no  period  of  time  that
  4105.  
  4106. slips   between  the  time-stamps).   The  offered  and  obtained
  4107.  
  4108. throughputs  through  each  protocol  module  are   also   useful
  4109.  
  4110. statistics.   In  addition,  if  a host can ever drop packets, it
  4111.  
  4112. should keep  track  of  this.   It  should  be  able  to  provide
  4113.  
  4114. information  as  to  what percentage of packets to (or from) each
  4115.  
  4116. destination host (or source host) were dropped, and  this  should
  4117.  
  4118. be further broken down into categories indicating why the packets
  4119.  
  4120. were  dropped.   (Reasons  for  hosts' dropping packets will vary
  4121.  
  4122. from implementation to implementation).
  4123.  
  4124.  
  4125.      Note that this sort of instrumentation  is  much  harder  to
  4126.  
  4127. implement if we are using datagram protocols than if we are using
  4128.  
  4129. protocols  with  more  control  information, because much of this
  4130.  
  4131. instrumentation is based on sent or received control information.
  4132.  
  4133. The less control information we have, the less we can instrument,
  4134.  
  4135. which  means  that  fault-isolation  and  performance  evaluation
  4136.  
  4137. become  much  harder.  This seems to be a significant, though not
  4138.  
  4139. yet widely-noticed, disadvantage of datagram protocols.
  4140.  
  4141.  
  4142.      Host personnel may want to consider having  some  amount  of
  4143.  
  4144. instrumentation in removable packages, rather than in permanently
  4145.  
  4146. resident  code.   This  ability  may  be essential for efficiency
  4147.  
  4148. reasons if the instrumentation code is either large or slow.   In
  4149.  
  4150.  
  4151.                              - 71 -
  4152.  
  4153.  
  4154. IEN 187                              Bolt Beranek and Newman Inc.
  4155.                                                     Eric C. Rosen
  4156.  
  4157.  
  4158. that  case,  it  might  be  necessary  to  load it in only when a
  4159.  
  4160. problem seems evident.   Instrumentation  should  also  have  the
  4161.  
  4162. ability to be turned on and off, so that it is possible to gather
  4163.  
  4164. data  over  particular  time  windows.   This is necessary if the
  4165.  
  4166. instrumentation is to be used as part of  the  evaluation  of  an
  4167.  
  4168. experiment.
  4169.  
  4170.  
  4171.  
  4172.  
  4173.  
  4174.  
  4175.  
  4176.  
  4177.  
  4178.  
  4179.  
  4180.  
  4181.  
  4182.  
  4183.  
  4184.  
  4185.  
  4186.  
  4187.  
  4188.  
  4189.  
  4190.  
  4191.  
  4192.  
  4193.  
  4194.  
  4195.  
  4196.  
  4197.  
  4198.  
  4199.  
  4200.  
  4201.  
  4202.  
  4203.  
  4204.  
  4205.  
  4206.  
  4207.  
  4208.  
  4209.                              - 72 -
  4210.  
  4211.  
  4212. IEN 187                              Bolt Beranek and Newman Inc.
  4213.                                                     Eric C. Rosen
  4214.  
  4215.  
  4216.                            REFERENCES
  4217.  
  4218. 1. "DOD   Standard  Internet  Protocol,"  COMPUTER  COMMUNICATION
  4219. REVIEW, October 1980, pp. 12-51.
  4220.  
  4221. 2.  "ARPANET Routing  Algorithm  Improvements,"  BBN  Report  No.
  4222. 4473, August 1980.
  4223.  
  4224.  
  4225.  
  4226.  
  4227.  
  4228.  
  4229.  
  4230.  
  4231.  
  4232.  
  4233.  
  4234.  
  4235.  
  4236.  
  4237.  
  4238.  
  4239.  
  4240.  
  4241.  
  4242.  
  4243.  
  4244.  
  4245.  
  4246.  
  4247.  
  4248.  
  4249.  
  4250.  
  4251.  
  4252.  
  4253.  
  4254.  
  4255.  
  4256.  
  4257.  
  4258.  
  4259.  
  4260.  
  4261.  
  4262.  
  4263.  
  4264.  
  4265.  
  4266.  
  4267.                              - 73 -
  4268.  
  4269.  
  4270. -------
  4271.